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
Dario Crivelli
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
Dario Crivelli
Please reproduce the following test:
- launch a new instance of IE8 (v 8.0.7600.16385)
- open the online Silverlight demo http://www.lightstreamer.com/demo/Silverlight_StockListDemo through the address bar
- activate the demo fully, through the subscribe button
- 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?
Dario Crivelli
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.
emiliob
After some analysis I found that our application sets as default HTTP request creator the ClientHttp one, instead of the default BrowserHttp. Doing this seems to somehow have side effects on the normal operations of Lightstreamer's API.
For the time being, I have worked that around by forcing the usage of BrowserHttp creator for requests created to the Lightstreamer URL, and now the browser process shuts cleanly down when its window is closed.
Thank you,
Emilio
PS
As a side note, I observed that I was not able to establish a streaming connection when using ClientHttp creator. I can now do that using BrowserHttp.
Dario Crivelli
Ok; admittedly, the ClientHttp configuration case is not handled by the library properly; it doesn't support streaming and, upon a streaming answer from the Server, the Silverlight runtime keeps a reading thread open, which prevents the whole process from closing until the answer has finished.
For the next release, our plans are to force the library to lean on the BrowserHttp case.
In principle, the issue may be related not only with the ClientHttp, but also with other cases in which the streaming answer is buffered.
This is because, even though the Stream-sense mechanism can overcome the problem by opening a polling session, it cannot force the closure of the streaming connection.
We will work on improving this aspect.
Anyway, our tests have always shown that, when the streaming connection is blocked by something in the middle (for instance, a proxy), the Silverlight runtime behaves differently and there is nothing preventing the process from closing.
