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 Andrea,

Andrea Zoppello wrote:

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.
Well, the above code does depend upon having the container creation code (wherever it is in your application) be run first...so that the container instances are present in the array returned from getAllContainers(). I'm not sure why the container instances are not present when the above code is run.
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??
I think I would have to see what code change you are talking about to say. Would you please open a bug for this and attach a patch with the code change in question? And then I could take a look at it.
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....
Well, I'm not sure if I would refer to the necessary understanding of the shared object API for group management as 'in depth'...but nonetheless it is where the group management functions for reliable group membership are exposed programmatically.
I think the shortest route to understanding is for you to examine BaseSharedObject. The DistributedEventAdmin class extends BaseSharedObject, and shared objects are:
1) Notified about group membership changes (asynchronously) via any/all the IEventProcessors registered. 2) Have access to ISharedObjectContext, which gives methods for getting at the current *local* group membership information.
I will try to create some further documentation for the shared object API over the next few weeks, but my own schedule is very full right now.
Also, if you would like some contract/direct support for this project please contact me at slewis at composent.com 

Thanks,

Scott

Back to the top