Skip to main content

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
[ecf-dev] Fwd: Re: Need further clarification on Distributed Event Admin


Hi Scott,

I confirm  ( probably for my bad english ) that there was a
misunderstood between us on what i'm doing.

I'm definitely trying to use *two different virtual machine*, when i
speak about an "equinox node" i mean
each node has it's own process ant it's own virtual machine.

So in my case each equinox is starting the bundle that create and
configure the DistributedEventAdmin.

I'll open a bugzilla bug on ECF because my problems could simply be
solved by avoid to set the jms client ID
on jms connection.

The class i've modified is the
"org.eclipse.ecf.provider.jms.channel.AbstractJMSChannel"  in the
"setupJMS method"
i've simply comment this line

//connection.setClientID(getLocalID().getName());

That solve the problem, btw i more elegant way could be to have a
configuration parameter/properties and let both
the case possible.

Andrea

Il 05/02/2010 16:15, Scott Lewis ha scritto:
 Hi Andrea,

 Andrea Zoppello wrote:
 Hi Scott,

 Thanks for the support and patience, btw i confirm that the code i've
 post it's not working:

 Here the code of the start method of my bundle:


 <stuff deleted>

 This code is supposed to create the container node if it's not
 present, otherwise to create a client node and then to connect to it.
 The createConfigureAndConnectContainer is the one from the
 AbstractEventAdmin application in the DistributedEventAdmin examples.

 I suppose the fisrt time ( in the first jvm ) in the first node the
 container is created and io the second node the client is created
 but the method that verify if there's  a container node seems not
 working.

 It's because the container creation is done by the
 createConfigureAndConnectContainer method...and this is only executed
 *after* the call to isThereEventAdminManager...so your code in
 isThereEventAdminManager always returns false.

 I guess I don't understand what you are trying to do...because the
 start method of any bundle is only going to be executed *once* (when
 the bundle is started), meaning that if this is the only code that
 creates container instances (via createConfigureAndConnectContainer)
 that it will only ever create one container instance.

 Perhaps I misunderstood what you are trying to do.  I had thought that
 you wanted to run more than one container instance (i.e. a client
 and/or a manager...or more than one client) in a single *process*.  If
 you want to run things in separate processes...i.e. separate
 vms...then the way to make sure that you have one manager and
 everything else is a client is to control the launching of the various
 processes (i.e. only start one manager, and start n clients).


 Regards the shared object api, yeah i'll invest some time to look at
 it, but i think in previous posts i've not explained very well my use
 case, i don't want the *distributed event admin itself* to take care
 of group changes.

 Ok.  You can/could also setup listeners on the container instance
 itself...i.e. IContainer.addListener(IContainerListener), and this
 listener will receive events of type IContainerConnectedEvent (join)
 and IContainerDisconnectedEvent (leave).   Also you can get the
 ISharedObjectContainerAdapter from the IContainer...e.g.

 ISharedObjectContainerAdapter adapter =
 (ISharedObjectContainerAdapter)
 container.getAdapter(ISharedObjectContainerAdapter.class)...and with
 that get access to the current group membership information...e.g.

 ID[] currentGroupMembers = adapter.getGroupMemberIDs();


 In my architecture one equinox node ( probably the best object to
 identify is the Spagicregistry ) are supposed to be notified about
 coming, and leaving of other
 equinox nodes and will use then use the distributed event admin to
 synchronize their services list.

 Ok, then access via the IContainerListener may be better/more
 appropriate.

 Scott






Back to the top