locked
HttpListener GetContext() hanging after two requests received RRS feed

  • Question

  • Hello,

    I am using the HttpListener GetContext() method to synchronously wait for new HTTP messages in listener service I've created.  Because of the low volume of messages, I haven't found a reason to listen asynchronously.  Below is some code from the ServiceWorkerMethod.  The httpListener object is instanciated earlier in the code, its prefixes are set and the Start() method is invoked.

                    do
                    {
                        //Start waiting for next message
                        if (httpListener.IsListening)
                        {
                            Log("Svc:  Waiting for next message...");
                            HttpListenerContext context = httpListener.GetContext();
                            HttpListenerRequest request = context.Request;
                            System.IO.StreamReader tmpreader = new System.IO.StreamReader(request.InputStream);
                            string tmptext = tmpreader.ReadToEnd();
                            Log("Svc:  Message received:  " + tmptext);
                        }
                        else
                        {
                            Log("Svc:  HTTLListener is no longer listening.");
                        }

    The problem I am running into is that the first two messages are always processed quickly, but as soon as I send a third message, something hangs up.  The "Svc:  Waiting for next message..." log entry is logged immediately after receiving and logging the first two messages, so I know GetContext() has been called.  But about 90 seconds passes before the message is received and logged.  The application sending the message also hangs for the 90 seconds before it shows that its message was received.

    This pattern repeats every time.  After the listener finally processes the 3rd message, I can again send two messages before the third hangs again.

    This hanging behavior does not happen when testing running the listener service on my development machine, but happens every time when running on my test server.

    Thanks in advance.
    Friday, January 29, 2010 9:23 PM

Answers

  • FYI...The issue was that the client was using its 2 allotted HTTP connections to the end-point (to send the first two messages) and then it waited for the timeout to elapse before it would send another message.  The reason it waited for the timeout is because it was not trying to process a response after each post.  Even though response handling is not included in this interface, the client needed to try to process a response in order for the client to understand that the connection was again available.
    • Marked as answer by tmcnabb21 Tuesday, February 16, 2010 7:07 PM
    Tuesday, February 16, 2010 7:07 PM

All replies

  • You are not disposing of the objects. In particular, the Context, HttpListenerResponse and Streams.

    Can you dispose them and try again?
    feroze
    --
    My blog (including System.Net topics

     Subscribe in a reader

    Instruction on how to create a tracelog with your System.Net application
    System.Net Links and HOWTOs
    Sunday, January 31, 2010 6:00 AM
  • Definitely a good idea to prevent memory leaks, and I went ahead and cleaned that up, but unfortunately that's not the cause of the problem.  Something is causing GetContext to not see any new http messages for about 90 seconds.  I'm afraid it is something that the server is doing, somehow restricting the number of http messages coming through on that port in a given timeframe.

    Thanks.
    Sunday, January 31, 2010 5:28 PM
  • FYI...The issue was that the client was using its 2 allotted HTTP connections to the end-point (to send the first two messages) and then it waited for the timeout to elapse before it would send another message.  The reason it waited for the timeout is because it was not trying to process a response after each post.  Even though response handling is not included in this interface, the client needed to try to process a response in order for the client to understand that the connection was again available.
    • Marked as answer by tmcnabb21 Tuesday, February 16, 2010 7:07 PM
    Tuesday, February 16, 2010 7:07 PM
  • FYI...The issue was that the client was using its 2 allotted HTTP connections to the end-point (to send the first two messages) and then it waited for the timeout to elapse before it would send another message.  The reason it waited for the timeout is because it was not trying to process a response after each post.  Even though response handling is not included in this interface, the client needed to try to process a response in order for the client to understand that the connection was again available.

    I do not understand. Could you give more explanation? Thanx.
    Wednesday, August 4, 2010 1:35 AM
  • It's been a while, but I will try.  The problem really wasn't with the sample code in the original post, it was with the client application that was calling it.  The client app was successfully sending two messages to the server service, but was then hanging up before sending the third.  At the time I originally posted, I probably thought that the issue was with the server service, so apologies for the confusion.

    According to the design documents worked out with the vendor who would be developing the "other side" of this interface, there would be no success/failure information provided in a response for any of the interface calls to be implemented.  Therefore, I did not at first implement any code to try to read response data.  I simply performed the HTTP Post and considered the interface execution complete.  Apparently, the fact that I did not try to process a response caused the connection to remain open until the timeout lapsed.  I could perform one more execution of the interface immediately, but now I had two connections open.  If I immediately tried to execute the interface a third time, everthing would hang because a third HTTP connection was not available.  I don't remember the specifics on the default of two available HTTP connections, but I had read that was the limit, which explained why my program was hanging on the third interface execution.

    Even though I would not be getting any helpful response information back from the other side of the interface, I needed to try to get the response.  Also, the fact that I got a response (even though it had no useful content) meant that the transmission had succeeded successfully.  If there was an issue such as the endpoint being unavailable, I would get the exception when trying to get the response, so it was an important error check. 

    Adding code like the below immediately after the Post code took care of the problem...

     

     

            try
            {
              using (HttpWebResponse webResponse = (HttpWebResponse)webRequest.GetResponse())
              {
                if (webResponse == null)
                {
                  log.LogVerbose("Response is null.");
                  return "";
                }
                StreamReader sr = new StreamReader(webResponse.GetResponseStream());
                string response = sr.ReadToEnd().Trim();
                sr.Close();
                return response;
              }
            }
            catch (Exception x)
            {
              throw new ISException("Failure occurred in the interface: " + x.Message);
            }
    
    

     

    Monday, August 9, 2010 4:52 PM