[
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,
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.
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 )
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
