Skip to main content
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
[ecf-dev] Re: Need further clarification on Distributed Event Admin 
Hi Scott,
When i'll finish my work, and had something working, i'll have no problem to make my conclusion public on ECF wiki or where you prefer, i'll be very happy to make my little contribution to the community. 

BTW there are ( probably for my fault ) a few things i've not solved yet.
I've developed a simple bundle following the code in the distributed event admin application that try to understand in in "a group" an "ECF Manager" is already registered. 

Following your suggestion the method i write looks like:

protected boolean isThereEventAdminManager(){
        IContainer[] containers = getContainerManager().getAllContainers();

        for ( int i=0; i< containers.length; i++){
ISharedObjectContainer soContainer = (ISharedObjectContainer) containers[i].getAdapter(ISharedObjectContainer.class); 
            if ((soContainer != null) && soContainer.isGroupManager())
                    return true;
        }

        return false;
    }
BTW as i run two equinox instances ( 2 virtual machines ) this method always return false because the Containers array is always empty also if the other nodes has 
already registered the event admin manager.
So at the moment i've not solved the problem of the "ECF Manager/Client" creations.
Maybe it's wrong but ( at least in the case of jms ) the problem of having multiple "managers" is because the clientID is set on the JMS Connection, because the the client ID is set on JMS Connection, i've commented the line that set the client id add i could successfully have more than one equinox node running on the 
same machine without problem.

Do you see any problem in not setting up the clientID on jms connection??
Regards the group management it seems before starting to write some code i need to get in depth and understand ECF Shared Object API. A suggestion for documentation is to take the JGroup tutorial and try to achieve the same with ECF.... 


Andrea

Il 05/02/2010 00:06, Scott Lewis ha scritto:

Hi Andrea,
Thanks for sending this description of your work with DistributedEventAdmin to the ecf-dev mailing list. Just for everyone else's reference, Andrea and I have been having a technical exchange on the ecf newsgroup, which you can see here: 

http://www.eclipse.org/forums/index.php?t=thread&frm_id=99&;

There are a couple of comments interspersed in Andrea's posting below.

Andrea Zoppello wrote:

Hi Scott,
Thank you for the response, i've no problem in moving out technical discussion 
on the mailing-list i'm already subscribed :-)
I'll take one or two days trying to make some practice with the suggestion you give me. 

BTW maybe it's better i'll explain what i'm trying to do:
1) In my project all service has a property identifing the service (custom.id ) 2) All OSGi service implements a common interface ( based on Messagging Concept, each service receive a message as 
the input and produce a message as the output )
3) My OSGi services are all implementing the EventHandler interface, and are all created using DSComponent Factories. 
The usage of DSComponent Factories is very useful for me because:

- It allows me to have multiple services for the same factory.
- It allows me to specify at "service creation time" the event admin-topic property for my service
So what happen to my service is that if the service is identified by "ServiceFoo" the component factory will specify "BASE/MESSAGES/ServiceFoo_<NODE_IDENTIFIER>" in the event topic properties. <Node_Identifier> is a string readed from a configuration file identifying a node.
To be quicky doing the things in this way let me to have each service to listen to a dedicated topic.
On top of this i built a message router, that use the event admin service to send message from one service to another. Obviously the message router has to have knowledge of the service registered in the system 
before sending a message.
For doing this i've implemented a Registry class to be aware all services registered in the system, this registry class use some "notification topics" on the distributed event admin to be aware of other nodes.
In my registry class i've successfully handled all situations except the situation in which one of the nodes crash, in that case the crashed node won't be able to notify to others and the registry state will be not consistent.
This is the reason why i've consider to use JGroup, for all other use case distributed admin within my Registry code class works for me, i've just tried with success to start more than one nodes in different orders ant it works perfect 
except for the use case described.
As we discussed on the newsgroup, ECF has a JGroups-based provider...available at the ECF OSU Open Source Lab CVS server: 

Anonymous access
host:  ecf1.osuosl.org
path:  /ecf
module:  plugins/org.eclipse.ecf.provider.jgroups
Eclipse:  :pserver:anonymous@xxxxxxxxxxxxxxx:/ecf

Extssh access (I administer this machine so can provide write access)
host:  ecf1.osuosl.org
path:  /home/cvs/ecf
same module
Eclipse:  :extssh:ecf1.osuosl.org:/home/cvs/ecf
This provider is based upon JGroups 2.5.0. It implements the ECF shared object API, and this API exposes access to group membership changes, as well as manipulation of group membership from the manager container.
The DistributedEventAdmin class (i.e. org.eclipse.ecf.remoteservice.eventadmin.DistributedEventAdmin) actually extends BaseSharedObject (i.e. org.eclipse.ecf.core.sharedobject.BaseSharedObject). This means that the DistributedEventAdmin is actually a shared object instance...and so subclasses of DistributedEventAdmin can/could receive events (such as group membership changes)...and respond to them by running arbitrary code. It sounds like this *might* be useful for your use case(s). 



To be briefly in my conclusion i had two different use cases
1) The need to distribute the Router implementation ( and this is jsut working simply using the ECF Distributed Event Admin Implementation ) 2) Mantain a consistent registry of my custom services in cluster configuration ( solved partially at the moment )
OK, sounds very good. Andrea...if you are able and willing it might be a good idea to create a wiki page of your use cases for DistributedEventAdmin...and how to setup/use the ECF implementation (with JGroups and/or some other provider). If you would be willing to do this it would be very helpful to the community, I think. If you have a bugzilla login, you can create wiki pages and add them to the ECF home page: http://wiki.eclipse.org/ECF.
I will happily assist in this, if desired (and of course will answer questions, etc). Even better, if you were able to contribute code, or identify bugs, or identify areas in either the API or implementation where generalization/improvement could be made that would also be most appreciated. And finally, if you were willing to blog publicly about this work (or allow me to) that would also be helpful...as I don't think a lot of people yet know about the DistributedEventAdmin and what it can do...especially with ECF's multi-provider architecture and the use of the shared object API. 

Thanks,

Scott




Andrea

Il 04/02/2010 15:55, Scott Lewis ha scritto:

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.ISharedObjectContainerGroupManager, 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

Back to the top