LS thread hangs on process exit

bartol82

Hi,

I now have an issue with normal process shutdown.

Everything works fine until I want to shutdown the host process for the remote data adapter. The process is hosted in a console application which "main" method exists but the process keeps running. Obviously there must be a non-background thread which prevents process exit.

I've then attached the VS debugger to the process and found an unnamed thread with this call stack:

[Managed to Native Transition]	
>	System.dll!System.Net.Sockets.Socket.Receive(byte[] buffer = {Dimensions :Smile_Ah: 1024]}, int offset = 0, int size, System.Net.Sockets.SocketFlags socketFlags = None, out System.Net.Sockets.SocketError errorCode = Success) + 0xd3 bytes	
 	System.dll!System.Net.Sockets.Socket.Receive(byte[] buffer, int offset, int size, System.Net.Sockets.SocketFlags socketFlags) + 0x21 bytes	
 	System.dll!System.Net.Sockets.NetworkStream.Read(byte[] buffer, int offset, int size) + 0x78 bytes	
 	mscorlib.dll!System.IO.StreamReader.ReadBuffer() + 0x5c bytes	
 	mscorlib.dll!System.IO.StreamReader.ReadLine() + 0x1f bytes	
 	DotNetAdapter_N2.dll!Lightstreamer.DotNet.Server.RequestReply.RequestReceiver.Run() + 0x40 bytes	
 	mscorlib.dll!System.Threading.ThreadHelper.ThreadStart_Context(object state) + 0x3b bytes	
 	mscorlib.dll!System.Threading.ExecutionContext.Run(System.Threading.ExecutionContext executionContext, System.Threading.ContextCallback callback, object state) + 0x81 bytes	
 	mscorlib.dll!System.Threading.ThreadHelper.ThreadStart() + 0x40 bytes

The thread is apparently blocked on the Socket.Receive() method.

Here is how the server gets started:

  server.RequestStream = _rrSocket.GetStream();
                server.ReplyStream = _rrSocket.GetStream();

                if (_notifSocket != null)
                {
                    server.NotifyStream = _notifSocket.GetStream();
                }

                OnConnected(EventArgs.Empty);
                server.Start();

On the process exit the server gets closed with the Close() method which results in the following log output:

2008-10-15 12:20:21,283 [9] INFO  Lightstreamer.DotNet.Server.RequestReply.NotifySender [(null)] - Reply sender '#1' stopped
2008-10-15 12:20:21,283  [8]INFO  Lightstreamer.DotNet.Server.RequestReply.NotifySender [(null)] - Notify sender '#1' stopped

Do I have to do something else/different?

Thanks.

Dario Crivelli

I confirm that the reading and writing threads opened by the "MetadataProviderServer" and "DataProviderServer" object instances are not background threads.
Even the sample code in "StandaloneLauncher.cs" takes advantage of this fact and doesn't keep the "main" method thread open in order to keep the Remote Server running.

Admittedly, only a limited support is provided for the forced closure of the "MetadataProviderServer" and "DataProviderServer" object instances.
The aim of the Close method is only to stop the threads in case an exception prevents the object from working.

In order to forcibly close the object, you should store the socket reference and close the socket directly;
you should also ensure that the ExceptionHandler property issues a Close, as shown in "StandaloneLauncher.cs".

Note that, upon closing the first socket, the Server may also react,
so that the other sockets may be closed either by your code or by the Server, whichever does it first.

Also note that the Metadata and Data Adapter instances may use their own threads as well; they should also be closed manually.
However, if you are using the StockListDemo Data Adapter, then consider that it does not support forced closure.

bartol82

Hi, thanks for the reply.

I see now that the behaviour you describe is indeed documented for the Close method (next time I will read more thoroughly). For the moment we will use the technique you describe (manual socket close), but as the Close() method exists, is there any chance that it will get upgraded in the future so that it really closes all of the server resources?

Also note that the Metadata and Data Adapter instances may use their own threads as well; they should also be closed manually.

This is all taken care off, as our .NET process (while testing we use a console app which in production becomes a windows service) host only our Data Adapter which supports graceful thread completion. The Metadata Adapter is written in Java.

Have a nice day,

Tomislav

Dario Crivelli

Ok, we will consider whether or not the current implementation of Close had better be extended.