[
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 services...so 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.
Thanks,
Scott
