[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
|
Re: [ecf-dev] remote service / zookeeper problems - it's working
|
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.
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.
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.
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.
Thanks for all the help.
Bryan
On Aug 19, 2010, at 9:03 AM, Scott Lewis wrote:
> Hi Bryan,
>
> Bryan Hunt wrote:
>> Hi Scott, how do I configure the container? I'm not creating the container in my code. I'm set up based on the instructions here: http://wiki.eclipse.org/Getting_Started_with_ECF%27s_OSGi_Remote_Services_Implementation except using DS instead of code to register my services.
>>
>
> There is an ECF service property 'org.eclipse.ecf.containerFactoryArgs' that is used to pass arguments to the host container creation. In code, the usage looks like this (this code is from HelloHostApplication class in org.eclipse.ecf.examples.remoteservices.hello.host). The containerId variable has the appropriate value
>
> Properties props = new Properties();
> // add OSGi service property indicated export of all interfaces exposed
> // by service (wildcard)
> props.put(IDistributionConstants.SERVICE_EXPORTED_INTERFACES,
> IDistributionConstants.SERVICE_EXPORTED_INTERFACES_WILDCARD);
> // add OSGi service property specifying config
> props.put(IDistributionConstants.SERVICE_EXPORTED_CONFIGS,
> containerType);
> // add ECF service property specifying container factory args
> props.put(
> IDistributionConstants.SERVICE_EXPORTED_CONTAINER_FACTORY_ARGUMENTS,
> containerId);
> // register remote service
> helloRegistration = bundleContext.registerService(
> IHello.class.getName(), new Hello(), props);
>
> In org.eclipse.ecf.examples.remoteservices.hello.host.ds there is markup that does the same thing:
>
> <scr:component xmlns:scr="http://www.osgi.org/xmlns/scr/v1.1.0"; enabled="true" immediate="true" name="org.eclipse.ecf.examples.remoteservices.hello.ds.host">
> <implementation class="org.eclipse.ecf.examples.internal.remoteservices.hello.ds.host.HelloComponent"/>
> <property name="service.exported.interfaces" type="String" value="*"/>
> <property name="service.exported.configs" type="String" value="ecf.generic.server"/>
> <property name="org.eclipse.ecf.containerFactoryArgs" type="String" value="ecftcp://localhost:30001/server"/>
> <service>
> <provide interface="org.eclipse.ecf.examples.remoteservices.hello.IHello"/>
> </service>
> <reference cardinality="1..1" interface="org.eclipse.ecf.core.IContainerFactory" name="IContainerFactory" policy="static"/>
> </scr:component>
>
>> Out of curiosity, why can't the container be configured with InetAddress.getLocalHost().getHostName() by default?
>
> It could...although as a global default this has some issues (e.g. the fact that getHostName() can/could block on some system...or there is no/wrong host name). I vaguely recall some difficulties with such issues for some ECF consumers that were using on devices...and I think that led to the use of 'localhost' as a safe default. Also, there is security...making things explicit (hopefully) at least makes developers more aware. But this is admittedly a lesser concern than ease-of-use.
>
> In any event, I'm open to changing it for the generic provider if we can work out the issues.
>
> Scott
>
>
>> Bryan
>>
>> On Aug 19, 2010, at 12:22 AM, Scott Lewis wrote:
>>
>>
>>> Hi Bryan,
>>>
>>> Bryan Hunt wrote:
>>>
>>>> I think part of my problem is my understanding of zookeeper and ECF containers. It appears that ECF starts a zookeeper server so having more than one ECF framework with zookeeper running on the same host causes port bind problems. It also appears that the ECF container is having a port conflict (not completely sure about this one).
>>>>
>>>> I moved my servers to different hosts, and now zookeeper is discovering the services, but the proxies are not registered on the consumer. When I restarted the consumer, I got the following exception:
>>>>
>>>>
>>>> Connect error in getRemoteServiceReferences;severity4;exception=org.eclipse.ecf.core.ContainerConnectException: Exception during connection to ecftcp://localhost:3282/server;children=[]]]
>>>> org.eclipse.ecf.core.ContainerConnectException: Exception during connection to ecftcp://localhost:3282/server
>>>> at org.eclipse.ecf.provider.generic.ClientSOContainer.connect(ClientSOContainer.java:176)
>>>> at org.eclipse.ecf.provider.generic.SOContext.connect(SOContext.java:112)
>>>> at org.eclipse.ecf.provider.remoteservice.generic.RegistrySharedObject.connectToRemoteServiceTarget(RegistrySharedObject.java:202)
>>>> at org.eclipse.ecf.provider.remoteservice.generic.RegistrySharedObject.getRemoteServiceReferences(RegistrySharedObject.java:178)
>>>> at org.eclipse.ecf.internal.osgi.services.distribution.DiscoveredServiceTrackerImpl.handleDiscoveredServiceAvailable(DiscoveredServiceTrackerImpl.java:230)
>>>> at org.eclipse.ecf.internal.osgi.services.distribution.DiscoveredServiceTrackerImpl.access$4(DiscoveredServiceTrackerImpl.java:197)
>>>> at org.eclipse.ecf.internal.osgi.services.distribution.DiscoveredServiceTrackerImpl$1.dispatchEvent(DiscoveredServiceTrackerImpl.java:102)
>>>> at org.eclipse.osgi.framework.eventmgr.EventManager.dispatchEvent(EventManager.java:227)
>>>> at org.eclipse.osgi.framework.eventmgr.EventManager$EventThread.run(EventManager.java:337)
>>>> Caused by: java.net.ConnectException: Connection refused
>>>> at java.net.PlainSocketImpl.socketConnect(Native Method)
>>>> at java.net.PlainSocketImpl.doConnect(PlainSocketImpl.java:352)
>>>> at java.net.PlainSocketImpl.connectToAddress(PlainSocketImpl.java:214)
>>>> at java.net.PlainSocketImpl.connect(PlainSocketImpl.java:201)
>>>> at java.net.SocksSocketImpl.connect(SocksSocketImpl.java:378)
>>>> at java.net.Socket.connect(Socket.java:537)
>>>> at org.eclipse.ecf.provider.comm.tcp.SocketFactory.createSocket(SocketFactory.java:26)
>>>> at org.eclipse.ecf.provider.comm.tcp.Client.connect(Client.java:181)
>>>> at org.eclipse.ecf.provider.generic.ClientSOContainer.connect(ClientSOContainer.java:146)
>>>> ... 8 more
>>>>
>>>> Why is the consumer trying to connect to localhost when the service is on a different host? Shouldn't zookeeper give ECF the proper host for the remote service?
>>>>
>>> I would guess from this error and your description of what you have done is that even though you have moved the servers to different hosts, you probably have started the servers using the default server id...which is: ecftcp://localhost:3282/server
>>>
>>> It uses localhost as the default rather than trying to choose/figure out a hostname...at least for the examples. So you should probably set the hostname explicitly upon server start/container creation (i.e. so it's not localhost, but rather a host which the consumer can find on the network.e.g. ecftcp://myhost.com:3282/server
>>>
>>> WRT zookeeper behavior I'll have to defer to Wim to answer...i.e. about how to enable/disable/configure zookeeper server in the case where you have more than one service being hosted.
>>>
>>> One question I have about your use case: All of the following are possible with ECF
>>>
>>> 1) two hosts/processes with one container per host (listening on whatever port), each container with a single service host
>>> 2) one host/process with two containers (listening on different ports necessarily), and a single service host within each container
>>> 3) one host/process with one container (listening on a single port), with *two* service hosts exposed by that container
>>>
>>> I'm not clear from your description of the use case whether any of these is preferred over another. They are all three possible, but have separate issues of configuration, startup, etc (as you might expect)...and depending upon desired/expected behavior, they can be more or less complicated to start, understand, coordinate, etc.
>>>
>>> Scott
>>>
>>>
>>>> If I ever get this working, I'll update my blog tutorial on remote services. Nobody should have to go through this much effort for something that should be simple.
>>>>
>>>> Bryan
>>>>
>>>> On Aug 18, 2010, at 9:21 PM, Bryan Hunt wrote:
>>>>
>>>>
>>>>> I'm trying to get OSGi remote services working with ECF 3.3 / zookeeper and ecf.generic.server
>>>>>
>>>>> I have a system with three processes using OSGi remote services: one is the consumer, and the other two are servers. The servers each publish one instance of the same remote service and this appears to be working correctly. If I look at the list of services on each of the servers, I see the service registered twice: once by my code, and once by org.eclipse.ecf.osgi.services.distribution. I see two sets of connections on the zookeeper console - one for each server. Here is the problem ...
>>>>>
>>>>> The consumer sees only one remote service instead of two - the service published by the server started first. Note that all processes are running in separate JVMs on the same machine. I also have the zookeeper server running on the same machine. Any ideas here? Is there tracing on a specific bundle that might help track down the problem? Any specific breakpoints I can set?
>>>>>
>>>>> Aside ...
>>>>>
>>>>> Also note that I've tried both jmdns and slp for discovery and neither one of them can get the service published on the server end. jmdns seems to choke on the number of parameters I need to configure the service, and slp simply throws an exception. I've debugged the jmdns problem a bit and I'll open a bug at some point, but right now, I'm really hoping to get zookeeper working.
>>>>>
>>>>> I'm going to try to dig deeper - any suggestions to reduce the debug time would be appreciated.
>>>>>
>>>>> Bryan
>>>>> _______________________________________________
>>>>> ecf-dev mailing list
>>>>> ecf-dev@xxxxxxxxxxx
>>>>> https://dev.eclipse.org/mailman/listinfo/ecf-dev
>>>>>
>>>> _______________________________________________
>>>> ecf-dev mailing list
>>>> ecf-dev@xxxxxxxxxxx
>>>> https://dev.eclipse.org/mailman/listinfo/ecf-dev
>>>>
>>> _______________________________________________
>>> ecf-dev mailing list
>>> ecf-dev@xxxxxxxxxxx
>>> https://dev.eclipse.org/mailman/listinfo/ecf-dev
>>>
>>
>> _______________________________________________
>> ecf-dev mailing list
>> ecf-dev@xxxxxxxxxxx
>> https://dev.eclipse.org/mailman/listinfo/ecf-dev
>>
>
> _______________________________________________
> ecf-dev mailing list
> ecf-dev@xxxxxxxxxxx
> https://dev.eclipse.org/mailman/listinfo/ecf-dev
