| Need further clarification on Distributed Event Admin [message #625121] |
Tue, 02 February 2010 13:10  |
 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 #625125 is a reply to message #625121] |
Wed, 03 February 2010 00:06  |
Scott Lewis
Messages: 1038
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
|
|
|
Powered by
FUDForum. Page generated in 0.02760 seconds
] 
Search
Help
Register
Login
Home
