[
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