Skip to main content

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: [ecf-dev] remote service / zookeeper problems - it's working

Hi Bryan,

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.):

containerFactory.createContainer("ecf.generic.server","ecftcp://myhost.com:4444/server");

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: http://wiki.eclipse.org/Customizing_and_Extending_ECF_Remote_Services

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.

Scott




Back to the top