Silverlight client hanged when closing the browser window

[emiliob]

Hi,

When I try to quit my silverlight client by closing the browser window, the browser process remains hang. It looks like that some internal trheads spawned by the Lightstreamer API are preventing the process from closing.

Please find attached the results of the analysis I carried out so far.
If you could help me sorting this issue out it would be great.

Thank you,
Emilio Bova

[DarioCrivelli]

The WaitOne calls in which the reported threads are stuck are supposed to have a short life. The involved monitor is used to wait for the outcome of a connection attempt and it is released after the connection attempt has completed with either success or failure.

When I try keeping the response blocked on the Server and closing the browser, it still closes immediately, though the process remains alive for a few seconds more.
Is that the issue you are reporting or, in your case, does the browser stay alive forever?
Otherwise, may you please help us replicating the issue?

[emiliob]

Hi,

Unfortunately the browser seems to stay alive forever. I've tried both with Firefox 3.6.3 and IE 8 (v 8.0.7600.16385) running my client on Silverlight 4, with the same result: the browser window closes, but the process remains there and I'm forced to kill it.

What would you require from my side to help you going on with the investigation?

Thanks,
Emilio

[DarioCrivelli]

Please reproduce the following test:

1. launch a new instance of IE8 (v 8.0.7600.16385)
2. open the online Silverlight demo http://www.lightstreamer.com/demo/Si..._StockListDemo through the address bar
3. activate the demo fully, through the subscribe button
4. close the browser

I see that two iexplore processes are created after step 1, then no more.
After step 4, the two processes disappear.
Do you notice the same?
If not, is there any other sequence of actions that triggers the issue (preferably based on the online demo)?
(I'm using windows 7 with Silverlight 4)

[emiliob]

I already tried that here (same configuration Win7+ SL4) both with the online version and a version hosted by my local Lightstreamer server and in those cases the browser did shut gracefully down after a very short while, as you described.

My client looks actually like the SL demo, but there is a substantial difference: I've put together a mechanism that automatically reconnects to the Lightstreamer server in case the connection is lost (basically by attempting a reconnection in a while if the previous connection attempt failed or an existing connection is dropped).

Please look at the file I attached to my first post. I believe that the only object that can keep a connection to a LS server alive is the LSClient class: is that correct?. In my case, I have two instances of LSClient that have strong reference. The one I suspect to be the culprit of the issue is actually alive only on the stack of a "SessionActivitymanager" thread (thread 43 in the report), while the other one is kept alive on another "SessionActivitymanager" thread (thread 45). No other threads - notably, application threads or background threads explicitly spawned by my application - are referencing any LSClient class.

What I imagine is that, for some reason, the fact that two LSClient are actually instanced prevents somehow those threads from shutting down.

Can you confirm this?

Coming to your question
> If not, is there any other sequence of actions that triggers the issue (preferably based on the online demo)?
I have not been able to identify yet a specific sequence of actions. It would seem that establishing a connection to a Lightstreamer server is enough to trigger that behaviour, but I do not have yet a specific sequence.

Please let me know your findings or if you would like me to perform more specific tests.

Thank you,
Emilio

PS
Should this analysis fail to yield results, might I propose to enhance the LSClient class with a "Dispose" or "Shutdown" method which would abort the service threads and release the resources? Or to provide an option to have SL API spawn "background" threads, that do not keep a process alive when exiting?

[DarioCrivelli]

Ok; if we had the opportunity to replicate the issue it would be easier.
Anyway, you are right and there are a couple of fixes that we can do to improve the management of the internal threads.

There is a caveat, though:
The thread involved in your thread dump, i.e. the thread which dequeues data from streaming connections (or waits for data on long polling connections) cannot be declared as a background thread,
because, during the normal session activity, it is possible that this thread is the only one active.

For now, we need that you try to replicate the issue with a test version of the Silverlight library, which we will be sending you privately.