[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [ecf-dev] remote service / zookeeper problems - it's working
- From: Scott Lewis <slewis@xxxxxxxxxxxxx>
- Date: Thu, 19 Aug 2010 16:36:11 -0700
- Delivered-to: firstname.lastname@example.org
- User-agent: Thunderbird 126.96.36.199 (Windows/20100228)
Bryan Hunt wrote:
I managed to get it all working. I had to configure the container as described below, and I had to move one of my servers to another host. If both of the servers are on the same host, only one remote service is seen by the consumer.
Hmmm. Do you know why this is? My first guess would be that for some
reason the zookeeper discovery is not publishing the second server's
info (for whatever reason), and so the consumer never discovers it...but
I don't know why that would be.
Something to consider is the configuration of the container. In my use-case, the value of the server id must be dynamic as the servers can be started on any host. Fortunately, my DS must be configured with ConfigurationAdmin, so I can dynamically set the server id value. This wouldn't work so well for someone trying to statically set the id in the service description.
So...just for your and everyone's information...there are several ways
that such a use case (dynamically determining the server id value) could
be supported (in addition to using ConfigurationAdmin with ds):
1) Register the service host in code (i.e.
bundleContext.registerService) rather than with ds...and explicitly
compute/get the appropriate value and set the service property
2) Create the server container in code...i.e. explicitly create the
server container using (e.g.):
and then register the remote service host.
3) Implement your own IHostContainerFinder and register it as a service
using the whiteboard pattern. This adds *a lot* of flexibility in how
containers are created/initialized by the OSGi remote service
implementatoin as ECF's implementation of the OSGi remote services spec
calls the highest priority IHostContainerFinder to handle the
creation/configuration of container instances upon remote service
registration. See this web page for some more description of
using/extending the DefaultHostContainerFinder:
Just to clarify my use-case: There are 1..n servers where each server runs in it's own JVM on any one of several thousand hosts. Each server is identical - it exports the same DS remote service - think load balancing. There is one consumer with a DS that depends on the remote service provided by the server. The dependency is configured as "dynamic" with cardinality 0..n. Discovery is done with a centralized zookeeper server.
For such use cases, it may very well make sense to use 3 above...i.e. to
control the way that host containers are created/configured.
The net of this is that it's working with two problems: I have to configure the server id, and I can't have more than one server on the same host.
Yeah...I believe the methods described above (particularly 3) should be
able to address both of these problems. The IHostContainerFinder (and
IProxyContainerFinder) were added as a way to allow finer-grained
control over the interaction between the ECF remote services impl and
the ECF container/provider architecture. As I don't think many have
used it yet it may need some fine tuning of the API (e.g. make methods
in DefaultHostContainerFinder and AbstractHostContainerFinder accessible
by subclasses), but if this is necessary for unanticipated use cases it
can be done.