Results 1 to 4 of 4
  1. #1
    Member
    Join Date
    Mar 2008
    Location
    zagreb
    Posts
    5

    LS thread hangs on process exit

    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:

    Code:
    [Managed to Native Transition]	
    >	System.dll!System.Net.Sockets.Socket.Receive(byte[] buffer = {Dimensions:[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:
    Code:
      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:
    Code:
    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.

  2. #2
    Administrator
    Join Date
    Jul 2006
    Location
    Milan
    Posts
    1,089
    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.

  3. #3
    Member
    Join Date
    Mar 2008
    Location
    zagreb
    Posts
    5
    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

  4. #4
    Administrator
    Join Date
    Jul 2006
    Location
    Milan
    Posts
    1,089
    Ok, we will consider whether or not the current implementation of Close had better be extended.

 

 

Similar Threads

  1. Replies: 16
    Last Post: January 9th, 2012, 12:30 PM
  2. Replies: 3
    Last Post: June 8th, 2011, 12:42 PM
  3. Null Pointer Exception in Thread
    By Sathyaayyanar in forum Adapter SDKs
    Replies: 1
    Last Post: September 2nd, 2010, 10:00 AM
  4. Replies: 2
    Last Post: August 31st, 2009, 01:58 PM
  5. Getting through IIS "Basic" authorization process
    By wmolde in forum Client SDKs
    Replies: 14
    Last Post: February 12th, 2008, 10:10 AM

Bookmarks

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •  
All times are GMT +1. The time now is 05:43 AM.