Re: [ecf-dev] remote service / zookeeper problems - it's working

[Scott Lewis <slewis@xxxxxxxxxxxxx>]

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