Skip to main content

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: [ecf-dev] ECF remote services leaking threads

 Hi Bryan,

On 10/15/2010 7:53 AM, Bryan Hunt wrote:
I think ECF is leaking threads under certain conditions when it discovers a remote service.  It appears that when a service is discovered, ECF creates an IRemoteServiceContainerAdapter:run thread, a RSRegistry Dispatcher thread, and three tcp threads: ping, rcv, and sndr.  As you have seen, I'm seeing problems with zookeeper undiscovering / discovering services when there appear to be network / process delays.  It is during this time that ECF creates and additional IRemoteServiceContainerAdapter:run thread, a RSRegistry Dispatcher thread, and three tcp threads.

These threads are all correct...i.e. needed for the transport/keepAlive (sdr, rcv, ping). The IRemoteServiceContainerAdapter is for receiving the remote service registry messages, and the dispatcher for running invocations of remote calls.

Note that the IRemoteServiceContainerAdapter thread and the dispatcher won't be shut down until the container is disposed.

Since the zookeeper discovery continues to have issues, these threads keep being created.

Yes, as new remote services are discovered, new containers with connections are formed and registry and registry dispatchers created for those remote services.

The main question WRT the possibility of leaking threads is: what happens when remote services are unregistered and undiscovered? It sounds like zookeeper discovery is having some strangeness WRT undiscovering remote I would expect that this could result in some problems...but also realize that the unregistration of a remote service host will not *disconnect* the containers...because their may be other remote services exposed via that same container (or even by the other side).

How the containers/connections are managed/disconnected/disposed isn't at all specified by OSGi remote services...but ECF exposes the IContainer interface to allow/support control over that. But the answer to whether threads are being leaked is dependent upon the use case...i.e. when (for the host and client/consumer) should everything be torn down?

Could you describe the host/client structure a little further...and the sequence of remote service registration and discovery...followed by use, unregistration/undiscovery? And if you have thread listings at some or all of these steps then we can check for leaking threads.



Back to the top