LightStreamer thread hangs when closing application

[PowerUser]

Hi,


Thank you for replying to me.


I've used "!eestack -ee" WinDbg-command, and I haven't seen any other live threads (dump file: https://drive.google.com/file/d/0B-L...it?usp=sharing [142mb]).


How do I close an application to terminate the LS-threads properly?

[DarioCrivelli]

I have managed to replicate the case, but only in very unusual conditions.

According to the previous thread dump (I would like to avoid delving into the memory dump in the first place) the client has just issued a rebind request and it is waiting for the answer, which is not coming.
This can be replicated by blocking the Server, but not by closing the Server (in the latter case, HttpWebRequest.BeginGetResponse would invoke its listener).
Do you notice any issues in the Server or in the network, such that a request reaches the Server but gets no answer?

As long as the client is waiting for a connection to be established, it is correct that it keeps the process alive, as the underlying session is still to be considered alive, until the reconnection timeout expires.
By the way, the reconnection timeout is the ReconnectionTimeoutMillis property of ConnectionInfo, but if a session is in smart polling, the whole PollingIdleMillis is added.
After the timeout expires, the connection attempt should be abandoned.

However, I acknowledge that there is a bug.
In fact, after the timeout expires, the underlying connection attempt is not interrupted;
hence the thread (which is still not a background thread) keeps the process alive until something happens on the network and this may last for unboundedly long.
We'll try to fix that behavior for the next release.
Sorry for the inconvenience.

For now, the application should cooperate.
When the reconnection timeout expires, the application receives an invocation of OnFailure on the IConnectionListener.
There, it should evaluate if the process must terminate and, in that case, force the termination through Environment.Exit.
On the other hand, if the process issues CloseConnection while the blocked reconnection attempt is in place, OnFailure will not be invoked and the session will close normally;
however, the case is also affected by the bug, hence, the process will still be kept alive.
So, also after invoking CloseConnection, the application should evaluate if the process must terminate and, in that case, force the termination through Environment.Exit.
Alternatively, you could handle both cases by acting in the OnClose callback, which is always invoked.

[DarioCrivelli]

I must correct myself (the last row only):
The alternative of leaning on OnClose is also not available, because OnClose may also not be invoked, as a consequence of the same bug.
(I have also moved the thread to the client stuff)

[PowerUser]

Hi,


Thank you for replying. Could you please announce the approximate date of the fix for this issue?
Looking forward for the solution, because it is very important to us.

[DarioCrivelli]

The fixed library will be delivered upon the next public release of LS.
No patch for LS 5.x has been planned at the moment;
so, the case should be the next alpha release of LS 6.0
(where the included .NET Client library will be still compatible with Server 5.x).
This should happen within a few months, but no date has been scheduled yet.

If you are a customer, with an active support & maintenance contract, then you can receive a library patch in short time, by requesting it to support@lightstreamer.com