[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [ecf-dev] ECF remote services leaking threads
- From: Bryan Hunt <bhunt@xxxxxxx>
- Date: Fri, 15 Oct 2010 15:50:51 -0500
- Delivered-to: email@example.com
Are you familiar with using YourKit? If so, I could send you the snapshot I just captured. I'm using 9.5.0 which is early access and does not require a license. If not, I'll try to extract the requested info into an email. If you would like the snapshot, ping me on skype: bryanhunttx
On Oct 15, 2010, at 10:47 AM, Scott Lewis wrote:
> 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.
> ecf-dev mailing list