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

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



Back to the top