Eclipse Community Forums
Forum Search:

Search      Help    Register    Login    Home
Home » Eclipse Projects » Eclipse Communications Framework (ECF) » Need further clarification on Distributed Event Admin
Need further clarification on Distributed Event Admin [message #511657] Tue, 02 February 2010 13:10 Go to next message
Andrea Zoppello is currently offline Andrea Zoppello
Messages: 48
Registered: July 2009
Member
Hi All,

I'm going on with my test of Distributed Event Admin, using the JMS implementation.

I'm quite satsified about my tests, but there are still some doubts on some points that are not clear to me.

I've not clear the difference between the EventAdminManager Application and Event Admin Client application, looking at the code it seems both are connecting and creating a connetcion to activemq broker on a topic called exampleTopic. ( i could see this in the activemq console ), the difference seems to be that the client application at certain point is calling a sendAndWait method and if this fails, an exeception is raised:

org.eclipse.ecf.core.ContainerConnectException: connect failed to tcp://localhost:61616/exampleTopic
at org.eclipse.ecf.provider.jms.channel.AbstractJMSClientChanne l.connect(AbstractJMSClientChannel.java:63)
at org.eclipse.ecf.provider.generic.ClientSOContainer.connect(C lientSOContainer.java:146)
at org.eclipse.ecf.examples.internal.eventadmin.app.AbstractEve ntAdminApplication.createConfigureAndConnectContainer(Abstra ctEventAdminApplication.java:172)
at org.eclipse.ecf.examples.internal.eventadmin.app.AbstractEve ntAdminApplication.startup(AbstractEventAdminApplication.jav a:65)
at org.eclipse.ecf.examples.internal.eventadmin.app.AbstractEve ntAdminApplication.start(AbstractEventAdminApplication.java: 105)
at org.eclipse.equinox.internal.app.EclipseAppHandle.run(Eclips eAppHandle.java:194)
at org.eclipse.core.runtime.internal.adaptor.EclipseAppLauncher .runApplication(EclipseAppLauncher.java:110)
at org.eclipse.core.runtime.internal.adaptor.EclipseAppLauncher .start(EclipseAppLauncher.java:79)
at org.eclipse.core.runtime.adaptor.EclipseStarter.run(EclipseS tarter.java:368)
at org.eclipse.core.runtime.adaptor.EclipseStarter.run(EclipseS tarter.java:179)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(Unknown Source)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(Unknown Source)
at java.lang.reflect.Method.invoke(Unknown Source)
at org.eclipse.equinox.launcher.Main.invokeFramework(Main.java: 559)
at org.eclipse.equinox.launcher.Main.basicRun(Main.java:514)
at org.eclipse.equinox.launcher.Main.run(Main.java:1311)
at org.eclipse.equinox.launcher.Main.main(Main.java:1287)
Caused by: java.io.IOException: timeout waiting for response
at org.eclipse.ecf.provider.jms.channel.AbstractJMSChannel.send AndWait(AbstractJMSChannel.java:366)
at org.eclipse.ecf.provider.jms.channel.AbstractJMSChannel.send AndWait(AbstractJMSChannel.java:346)
at org.eclipse.ecf.provider.jms.channel.AbstractJMSClientChanne l.getConnectResult(AbstractJMSClientChannel.java:77)
at org.eclipse.ecf.provider.jms.channel.AbstractJMSClientChanne l.connect(AbstractJMSClientChannel.java:58)
... 17 more

Debugging on the code it seems that the EventAdminManager application is creating an AbstractJMSserverChannel, instead the Client application is using an AbstractJMSClientChannel.


I'm looking at this because i'm basically trying to solve the problem of having two equinox instances on the same machine "both" using the distributed event admin. The problem is that if i try to create the application in the same way of the EventAdminManager application i've the exception saying that i cannot have the same clientID, so i'm trying to find the better solution for me.

A solution i've find is to modify the method "setupJMS" in the AbstractJMSChannel and not set the ClientID but i don't know if this is the right way.

In General it would be great, if someone could explain in detail what happens at JMS level in the two application Manager and Server.

Thanks in advance if someone could help.


Andrea

Re: Need further clarification on Distributed Event Admin [message #511803 is a reply to message #511657] Wed, 03 February 2010 00:06 Go to previous messageGo to next message
Scott Lewis is currently offline Scott Lewis
Messages: 971
Registered: July 2009
Senior Member
Hi Andrea,

Andrea Zoppello wrote:
> Hi All,
>
> I'm going on with my test of Distributed Event Admin, using the JMS
> implementation.
>
> I'm quite satsified about my tests, but there are still some doubts on
> some points that are not clear to me.
>
> I've not clear the difference between the EventAdminManager Application
> and Event Admin Client application, looking at the code it seems both
> are connecting and creating a connetcion to activemq broker on a topic
> called exampleTopic. ( i could see this in the activemq console ), the
> difference seems to be that the client application at certain point is
> calling a sendAndWait method and if this fails, an exeception is raised:
>
> org.eclipse.ecf.core.ContainerConnectException: connect failed to
> tcp://localhost:61616/exampleTopic
> at org.eclipse.ecf.provider.jms.channel.AbstractJMSClientChanne
> l.connect(AbstractJMSClientChannel.java:63)
> at org.eclipse.ecf.provider.generic.ClientSOContainer.connect(C
> lientSOContainer.java:146)
> at org.eclipse.ecf.examples.internal.eventadmin.app.AbstractEve
> ntAdminApplication.createConfigureAndConnectContainer(Abstra
> ctEventAdminApplication.java:172)
> at org.eclipse.ecf.examples.internal.eventadmin.app.AbstractEve
> ntAdminApplication.startup(AbstractEventAdminApplication.jav a:65)
> at org.eclipse.ecf.examples.internal.eventadmin.app.AbstractEve
> ntAdminApplication.start(AbstractEventAdminApplication.java: 105)
> at org.eclipse.equinox.internal.app.EclipseAppHandle.run(Eclips
> eAppHandle.java:194)
> at org.eclipse.core.runtime.internal.adaptor.EclipseAppLauncher
> .runApplication(EclipseAppLauncher.java:110)
> at org.eclipse.core.runtime.internal.adaptor.EclipseAppLauncher
> .start(EclipseAppLauncher.java:79)
> at org.eclipse.core.runtime.adaptor.EclipseStarter.run(EclipseS
> tarter.java:368)
> at org.eclipse.core.runtime.adaptor.EclipseStarter.run(EclipseS
> tarter.java:179)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at sun.reflect.NativeMethodAccessorImpl.invoke(Unknown Source)
> at sun.reflect.DelegatingMethodAccessorImpl.invoke(Unknown Source)
> at java.lang.reflect.Method.invoke(Unknown Source)
> at org.eclipse.equinox.launcher.Main.invokeFramework(Main.java: 559)
> at org.eclipse.equinox.launcher.Main.basicRun(Main.java:514)
> at org.eclipse.equinox.launcher.Main.run(Main.java:1311)
> at org.eclipse.equinox.launcher.Main.main(Main.java:1287)
> Caused by: java.io.IOException: timeout waiting for response
> at org.eclipse.ecf.provider.jms.channel.AbstractJMSChannel.send
> AndWait(AbstractJMSChannel.java:366)
> at org.eclipse.ecf.provider.jms.channel.AbstractJMSChannel.send
> AndWait(AbstractJMSChannel.java:346)
> at org.eclipse.ecf.provider.jms.channel.AbstractJMSClientChanne
> l.getConnectResult(AbstractJMSClientChannel.java:77)
> at org.eclipse.ecf.provider.jms.channel.AbstractJMSClientChanne
> l.connect(AbstractJMSClientChannel.java:58)
> .. 17 more
>
> Debugging on the code it seems that the EventAdminManager application is
> creating an AbstractJMSserverChannel, instead the Client application is
> using an AbstractJMSClientChannel.

That's right. The AbstractJMSServerChannel should probably be named
AbstractJMSManagerChannel, but it's probably too late now to make such a
change without causing a lot of difficulties.

The reason for the JMSServerChannel is that in ECF's shared object API,
there is the concept of a 'group manager'. This is a concept useful for
two important aspects of pub/sub messaging: reliability and security.
For reliability, what the group manager provides is the ability to
synchronize dynamic group membership...i.e. to make sure that everyone
in the group reliably knows about the other participants in the group.
In some systems this is called having a consistent 'view' of the group
membership. The shared object API has built-in communication about
group membership changes (i.e. clients coming and going) as they occur.
In this way, all the group members can maintain a consistent 'view' of
what other clients/processes are in the group, and which are not. This
is important for detecting and responding to failure...i.e. if a member
leaves the group, then this can/will result in the other group members
being notified about this, and messaging to that group member will
reliably fail...as it should. In systems without group membership there
can/will be situations where group membership is uncertain (i.e. some
members think another process is 'there'/in the group, while others
think it's not).

For security, a group manager allows access control decisions (i.e.
clients joining the group) to be controlled by the group manager (if
desired). So, for example, for a new client to be allowed to join, the
group manager has to agree to it...and so it can therefore be refused.
This is useful for many use cases in pub/sub groups.

So the ECF shared object API has this concept of group membership
management, consistent 'views' of group membership, reliable failure
detection (which is very important), and a centralized way to do group
access control...i.e. group join. The ECF remote services API is
actually *implemented* as a shared object (specifically
RegistrySharedObject class in org.eclipse.ecf.provider.remoteservice).
This allows the *same* implementation of the ECF remote service API to
be reused across different transports (i.e. this same implementation is
used for ECF generic, JMS, JavaGroups, and XMPP providers). And that's
all because it's implemented *as* a shared object, and has the shared
object API underneath it (on all those transports).

>
>
> I'm looking at this because i'm basically trying to solve the problem of
> having two equinox instances on the same machine "both" using the
> distributed event admin. The problem is that if i try to create the
> application in the same way of the EventAdminManager application i've
> the exception saying that i cannot have the same clientID, so i'm trying
> to find the better solution for me.

Right...there is only one group manager for a given JMS topic. There
are n clients, however. Note that clients can both send and receive
events via the EventAdmin service.

>
> A solution i've find is to modify the method "setupJMS" in the
> AbstractJMSChannel and not set the ClientID but i don't know if this is
> the right way.
>
> In General it would be great, if someone could explain in detail what
> happens at JMS level in the two application Manager and Server.

Hopefully the above explanation helps. If it's insufficiently clear, or
more detail is desired, please let me know and I'll provide it...with or
without pointers into the implementation code (your choice).

Scott
Re: Need further clarification on Distributed Event Admin [message #512184 is a reply to message #511803] Thu, 04 February 2010 10:48 Go to previous messageGo to next message
Andrea Zoppello is currently offline Andrea Zoppello
Messages: 48
Registered: July 2009
Member
Hi Scott,

Thank you for the great explanation, after reading your response a lot of things that i was confused about are a bit clear quite now.

I finally understand that ECF have and manage a concept of group membersghip ( like the one jgroup has.... ).

This group/membership management is quite interesting for me because at the moment i've used the DistributedEventAdmin implementation successfully, but i also need *group management* features too...

My initial idea was to use:

1) ECF for the distributed event admin stuff
2) Implementing something based on Jgroup to have node on cluster to be aware when other nodes coming up and go down.

Now after reading your post it seems ECF could cover also the point 2). Is there any example or tutorial about group/member management with ECF API. A simple example with two nodes receiving notifyng could be enough.

I've a last question:

In my equinox node ( where i'm going ) to setup the distribute event admin i want to implement something like " if there's already a group manager create a client container ) else create and setup a group manager ( ECF server manager ) container"

I think this is possible but i dont't know how to detect if the ECF manager is available...

Thanks

Andrea
Re: Need further clarification on Distributed Event Admin [message #512282 is a reply to message #512184] Thu, 04 February 2010 14:55 Go to previous message
Scott Lewis is currently offline Scott Lewis
Messages: 971
Registered: July 2009
Senior Member
Hi Andrea,

Andrea Zoppello wrote:
> Hi Scott,
>
> Thank you for the great explanation, after reading your response a lot
> of things that i was confused about are a bit clear quite now.
>
> I finally understand that ECF have and manage a concept of group
> membersghip ( like the one jgroup has.... ).
>
> This group/membership management is quite interesting for me because at
> the moment i've used the DistributedEventAdmin implementation
> successfully, but i also need *group management* features too...
>
> My initial idea was to use:
>
> 1) ECF for the distributed event admin stuff
> 2) Implementing something based on Jgroup to have node on cluster to be
> aware when other nodes coming up and go down.
>
> Now after reading your post it seems ECF could cover also the point 2).

Yes. Just a little more information on this...ECF has an API called the
'shared object' API (i.e. org.eclipse.ecf.sharedobject). This is the
API that implements reliable group membership/management. The API
exposes various methods to get at group membership information and get
access to manipulating the group members (e.g. see
org.eclipse.ecf.core.sharedobject.ISharedObjectContainer which extends
org.eclipse.ecf.core.IReliableContainer ...which exposes group
membership access information). See also
org.eclipse.ecf.core.sharedobject.ISharedObjectContainerGrou pManager,
which is implemented by the group manager, and provides some group
membership control information.

Now, just for your information...the DistributedEventAdmin is actually
*implemented* using the shared object API. So it should be possible for
you to use the existing DistributedEventAdmin implemention *and*
access/use the shared object API for your other use cases.

Finally, I'm not sure whether you were aware of this, but we have a
jGroups 2.4.1-based ECF provider *and it already implements the shared
object API*. Meaning that it can right now serve be used with the
DistributedEventAdmin, and the jgroups group membership functions (over
multicast) can be accessed via the shared object API.

> Is there any example or tutorial about group/member management with ECF
> API. A simple example with two nodes receiving notifyng could be enough.

Unfortunately, there is not yet such a tutorial. I would like to have
one, but just haven't had the opportunity. However, if you look in
org.eclipse.ecf.core.sharedobject.BaseSharedObject (which, incidently is
the superclass for DistributedEventAdmin), you will see

1) that the shared object/distributed event admin is provided an
org.eclipse.ecf.core.sharedobject.ISharedObjectContext upon creation,
and can access group membership information via this context (which
means that if you extend DistributedEventAdmin you can/could call these
ISharedObjectContext methods as you wish.
2) the shared object has method addEventProcessor(IEventProcessor),
which allows shared object event notifications...of group membership
changes...to be responded to with your code.

Also, I would like to move toward such a tutorial myself...so if I can
help via responses to questions I will be able to use that to compile
such a tutorial eventually.

Oh, BTW...if at all possible I would like to have detailed technical
discussions on the ecf-dev mailing list...because there are more people
that regularly read that mailing list...and I think many of them
could/would benefit from your observations, use cases, and questions.
Do you think it would be possible to move this discussion to that
mailing list?

If you need instructions about how to join the mailing list, see
https://dev.eclipse.org/mailman/listinfo/ecf-dev


>
> I've a last question:
>
> In my equinox node ( where i'm going ) to setup the distribute event
> admin i want to implement something like " if there's already a group
> manager create a client container ) else create and setup a group
> manager ( ECF server manager ) container"
>
> I think this is possible but i dont't know how to detect if the ECF
> manager is available...


It should be possible to do by using the IContainerManager service to
iterate through the existing containers (e.g.
IContainerManager.getAllContainers()), and test each one for whether
it's a manager (e.g. by getting the ISharedObjectContainerAdapter for
the container...and if it's non-null calling
ISharedObjectContainerAdapter.isGroupManager()).

Unless I'm misunderstanding your use case here...which is possible, of
course.

Thanks,

Scott
Re: Need further clarification on Distributed Event Admin [message #625130 is a reply to message #511803] Thu, 04 February 2010 10:48 Go to previous message
Andrea Zoppello is currently offline Andrea Zoppello
Messages: 48
Registered: July 2009
Member
Hi Scott,

Thank you for the great explanation, after reading your response a lot of things that i was confused about are a bit clear quite now.

I finally understand that ECF have and manage a concept of group membersghip ( like the one jgroup has.... ).

This group/membership management is quite interesting for me because at the moment i've used the DistributedEventAdmin implementation successfully, but i also need *group management* features too...

My initial idea was to use:

1) ECF for the distributed event admin stuff
2) Implementing something based on Jgroup to have node on cluster to be aware when other nodes coming up and go down.

Now after reading your post it seems ECF could cover also the point 2). Is there any example or tutorial about group/member management with ECF API. A simple example with two nodes receiving notifyng could be enough.

I've a last question:

In my equinox node ( where i'm going ) to setup the distribute event admin i want to implement something like " if there's already a group manager create a client container ) else create and setup a group manager ( ECF server manager ) container"

I think this is possible but i dont't know how to detect if the ECF manager is available...

Thanks

Andrea
Re: Need further clarification on Distributed Event Admin [message #625132 is a reply to message #625130] Thu, 04 February 2010 14:55 Go to previous message
Scott Lewis is currently offline Scott Lewis
Messages: 971
Registered: July 2009
Senior Member
Hi Andrea,

Andrea Zoppello wrote:
> Hi Scott,
>
> Thank you for the great explanation, after reading your response a lot
> of things that i was confused about are a bit clear quite now.
>
> I finally understand that ECF have and manage a concept of group
> membersghip ( like the one jgroup has.... ).
>
> This group/membership management is quite interesting for me because at
> the moment i've used the DistributedEventAdmin implementation
> successfully, but i also need *group management* features too...
>
> My initial idea was to use:
>
> 1) ECF for the distributed event admin stuff
> 2) Implementing something based on Jgroup to have node on cluster to be
> aware when other nodes coming up and go down.
>
> Now after reading your post it seems ECF could cover also the point 2).

Yes. Just a little more information on this...ECF has an API called the
'shared object' API (i.e. org.eclipse.ecf.sharedobject). This is the
API that implements reliable group membership/management. The API
exposes various methods to get at group membership information and get
access to manipulating the group members (e.g. see
org.eclipse.ecf.core.sharedobject.ISharedObjectContainer which extends
org.eclipse.ecf.core.IReliableContainer ...which exposes group
membership access information). See also
org.eclipse.ecf.core.sharedobject.ISharedObjectContainerGrou pManager,
which is implemented by the group manager, and provides some group
membership control information.

Now, just for your information...the DistributedEventAdmin is actually
*implemented* using the shared object API. So it should be possible for
you to use the existing DistributedEventAdmin implemention *and*
access/use the shared object API for your other use cases.

Finally, I'm not sure whether you were aware of this, but we have a
jGroups 2.4.1-based ECF provider *and it already implements the shared
object API*. Meaning that it can right now serve be used with the
DistributedEventAdmin, and the jgroups group membership functions (over
multicast) can be accessed via the shared object API.

> Is there any example or tutorial about group/member management with ECF
> API. A simple example with two nodes receiving notifyng could be enough.

Unfortunately, there is not yet such a tutorial. I would like to have
one, but just haven't had the opportunity. However, if you look in
org.eclipse.ecf.core.sharedobject.BaseSharedObject (which, incidently is
the superclass for DistributedEventAdmin), you will see

1) that the shared object/distributed event admin is provided an
org.eclipse.ecf.core.sharedobject.ISharedObjectContext upon creation,
and can access group membership information via this context (which
means that if you extend DistributedEventAdmin you can/could call these
ISharedObjectContext methods as you wish.
2) the shared object has method addEventProcessor(IEventProcessor),
which allows shared object event notifications...of group membership
changes...to be responded to with your code.

Also, I would like to move toward such a tutorial myself...so if I can
help via responses to questions I will be able to use that to compile
such a tutorial eventually.

Oh, BTW...if at all possible I would like to have detailed technical
discussions on the ecf-dev mailing list...because there are more people
that regularly read that mailing list...and I think many of them
could/would benefit from your observations, use cases, and questions.
Do you think it would be possible to move this discussion to that
mailing list?

If you need instructions about how to join the mailing list, see
https://dev.eclipse.org/mailman/listinfo/ecf-dev


>
> I've a last question:
>
> In my equinox node ( where i'm going ) to setup the distribute event
> admin i want to implement something like " if there's already a group
> manager create a client container ) else create and setup a group
> manager ( ECF server manager ) container"
>
> I think this is possible but i dont't know how to detect if the ECF
> manager is available...


It should be possible to do by using the IContainerManager service to
iterate through the existing containers (e.g.
IContainerManager.getAllContainers()), and test each one for whether
it's a manager (e.g. by getting the ISharedObjectContainerAdapter for
the container...and if it's non-null calling
ISharedObjectContainerAdapter.isGroupManager()).

Unless I'm misunderstanding your use case here...which is possible, of
course.

Thanks,

Scott
Previous Topic:Using RemoteServices
Next Topic:"required items could not be found" error during ECF install
Goto Forum:
  


Current Time: Fri Oct 31 07:58:01 GMT 2014

Powered by FUDForum. Page generated in 0.02590 seconds
.:: Contact :: Home ::.

Powered by: FUDforum 3.0.2.
Copyright ©2001-2010 FUDforum Bulletin Board Software