Silverlight client hanged when closing the browser window

[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.

[DarioCrivelli]

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.