Jetty
  1. Jetty
  2. JETTY-155

Jetty 5 closes sockets differently than Jetty 4

    Details

    • Type: Improvement Improvement
    • Status: Resolved Resolved
    • Priority: Major Major
    • Resolution: Fixed
    • Affects Version/s: None
    • Fix Version/s: None
    • Component/s: None
    • Labels:
      None
    • Number of attachments :
      0

      Description

      Greg asked me to open a ticket for this so here is a dump of the email conversation that we had on the support list.

      I am using 5.1.11RC0. I can't quite duplicate the extact conversation using telnet. A couple of things would have to change: 1) in the request, do not send the Connection: close header, 2) if you do #1, Jetty no longer includes the Connection: close header in the response but the issue I am seeing happens when the Connection: close header is in the response. I can simulate the converstation with the following simple JSP:

      <% response.setHeader( "Connection", "close" ); response.setStatus( 404 ); return; %>

      So, if I request that JSP with telnet:

      GET /t404.jsp HTTP/1.1
      Host: localhost

      that simulates my issue. With Jetty 4, Jetty appears to recognize the fact that the Connection: close header was in the response and it closes the socket. In Jetty 5, it seems to ignore it and leaves the socket open until the idle timer kicks in and closes the socket.

      Tony

      ----Original Message----
      From: Greg Wilkins gregw@webtide.com
      Sent: Wednesday, September 13, 2006 11:47 AM
      Subject: Re: Jetty 4 vs. Jetty 5

      Tony,

      Can you tell me the exact version of Jetty 5 that you are using?

      I need to do a Jetty 5 maint release soon and I will look at this issue if I can reproduce it.

      If you look at the simple test I did below, you can see that Jetty 5.1.11RC0 is closing the connection. So can you test with a simple telnet and see if the connection is closed?

      [501] telnet localhost 8080
      Trying 127.0.0.1...
      Connected to localhost.
      Escape character is '^]'.
      GET /notexist.txt HTTP/1.1
      Host: localhost
      Connection: close

      HTTP/1.1 404 %2Fnotexist%2Etxt+Not+Found
      Date: Wed, 13 Sep 2006 15:45:01 GMT
      Server: Jetty/5.1.11RC0 (Linux/2.6.15-26-686 i386 java/1.5.0_06
      Connection: close
      Content-Type: text/html
      Content-Length: 1253

      <html>
      <head>
      <title>Error 404 /notexist.txt Not Found</title> </head> <body> <h2>HTTP ERROR: 404</h2><pre>/notexist.txt Not Found</pre> <p>RequestURI=/notexist.txt</p> <p><i><small><a href="http://jetty.mortbay.org">Powered by Jetty://</a></small></i></p>

      </body>
      </html>
      Connection closed by foreign host.

      Tony Thompson wrote:
      > I have apparently run across what I feel is a crappy HTTP client but,
      > crappy HTTP client works differently with Jetty 4 than it does with
      > Jetty 5. Here is basically what is happening:
      >
      > Jetty responds to some request with an HTTP 404. The response
      > contains a Connection: close header. With Jetty 4, the TCP FIN flag
      > is set in the packet that includes the 404 response. With Jetty 5,
      > the server sends the 404 WITHOUT the TCP FIN flag set in the packet.
      >
      > So, with Jetty 4, the socket close is dealt with and everyone goes
      > away happy. With Jetty 5, since the server didn't close the socket,
      > the client is apparently not closing the socket either even though
      > Connection: close was sent. So, the client hangs out until the server
      > detects the connection is idle and shuts down the socket. Once that
      > happens, the client continues on its merry way.
      >
      > From what I can tell, I have the socket listener configured the same
      > in Jetty 5 as I did in Jetty 4. Is there something in Jetty that
      > changed or is there something I can configure differently in Jetty 5
      > to make it work the way it did in Jetty 4?
      >
      > As an aside, am I even correct in assuming that Jetty 5 is allowed to
      > behave this way?

        Activity

        Greg Wilkins made changes -
        Field Original Value New Value
        Assignee Greg Wilkins [ gregw ]
        Hide
        Greg Wilkins added a comment -

        The return was causing some grief for JSP 2.1

        But I tried this against jetty-6 trunk and it works fine:

        [502] telnet localhost 8080
        Trying 127.0.0.1...
        Connected to localhost.
        Escape character is '^]'.
        GET /test/t404.jsp HTTP/1.1
        Host: localhost

        HTTP/1.1 404 Not Found
        Content-Type: text/html; charset=ISO-8859-1
        Expires: Thu, 01 Jan 1970 00:00:00 GMT
        Set-Cookie: JSESSIONID=fpcbk7c6s418g;path=/test
        Connection: close
        Server: Jetty(6.1-SNAPSHOT)

        <h1>MY BAD</h1>
        Connection closed by foreign host.

        Show
        Greg Wilkins added a comment - The return was causing some grief for JSP 2.1 But I tried this against jetty-6 trunk and it works fine: [502] telnet localhost 8080 Trying 127.0.0.1... Connected to localhost. Escape character is '^]'. GET /test/t404.jsp HTTP/1.1 Host: localhost HTTP/1.1 404 Not Found Content-Type: text/html; charset=ISO-8859-1 Expires: Thu, 01 Jan 1970 00:00:00 GMT Set-Cookie: JSESSIONID=fpcbk7c6s418g;path=/test Connection: close Server: Jetty(6.1-SNAPSHOT) <h1>MY BAD</h1> Connection closed by foreign host.
        Hide
        Tony Thompson added a comment -

        So, the answer is Jetty 6? Right now we just cranked down the idle connection time on the Jetty 5 server and that is helping the situation though, not the perfect solution.

        Not sure why the return causes grief unless there were blank lines lines in the file after the %> or even one CR. That might do it.

        I will test the JSP on Jetty 6 and see how it behaves for me.

        Show
        Tony Thompson added a comment - So, the answer is Jetty 6? Right now we just cranked down the idle connection time on the Jetty 5 server and that is helping the situation though, not the perfect solution. Not sure why the return causes grief unless there were blank lines lines in the file after the %> or even one CR. That might do it. I will test the JSP on Jetty 6 and see how it behaves for me.
        Hide
        Greg Wilkins added a comment -

        Tony,

        sorry I didn't see the 5.1.11 bit.... Just assumed jetty 6
        Jetty 6 is the answer.... but I will also look at jetty 5 shortly to see what the problem is.

        Show
        Greg Wilkins added a comment - Tony, sorry I didn't see the 5.1.11 bit.... Just assumed jetty 6 Jetty 6 is the answer.... but I will also look at jetty 5 shortly to see what the problem is.
        Greg Wilkins made changes -
        Issue Type Bug [ 1 ] Improvement [ 4 ]
        Hide
        Tony Thompson added a comment -

        Any chance I can get some more help with this issue? Our customer has indicated that the response times for their application have now become unacceptable again (not sure why the workaround was good before but now it is not). We are not going to be on Jetty 6 any time soon so let me know what it would take to get this resolved in Jetty 5.

        Thanks.

        Show
        Tony Thompson added a comment - Any chance I can get some more help with this issue? Our customer has indicated that the response times for their application have now become unacceptable again (not sure why the workaround was good before but now it is not). We are not going to be on Jetty 6 any time soon so let me know what it would take to get this resolved in Jetty 5. Thanks.
        Hide
        Greg Wilkins added a comment -

        The issue was with content that set close, but that jetty also knew (or could guess) the content length.
        fixed in cvs now.

        new release soon

        Show
        Greg Wilkins added a comment - The issue was with content that set close, but that jetty also knew (or could guess) the content length. fixed in cvs now. new release soon
        Greg Wilkins made changes -
        Status Open [ 1 ] Resolved [ 5 ]
        Resolution Fixed [ 1 ]

          People

          • Assignee:
            Greg Wilkins
            Reporter:
            Tony Thompson
          • Votes:
            0 Vote for this issue
            Watchers:
            0 Start watching this issue

            Dates

            • Created:
              Updated:
              Resolved: