Jetty
  1. Jetty
  2. JETTY-338

CLONE -NPE in HttpParser.isMoreInBuffer

    Details

    • Type: Bug Bug
    • Status: Resolved Resolved
    • Priority: Blocker Blocker
    • Resolution: Fixed
    • Affects Version/s: 6.1.2rc2
    • Fix Version/s: None
    • Component/s: NIO
    • Labels:
      None
    • Environment:
      Windows Vista dual core.
    • Testcase included:
      yes
    • Number of attachments :
      0

      Description

      In trying to track down what we think is a buffer problem in Jetty, I ran across this NullPointerException while doing some stress testing with the testBufferProblem() test in the attached JUnit test (our copy of the HttpServerTest class).

      2007-04-30T18:58:11.698 | ERROR | btpool0-3     |                                               | log                            | handle failed
      java.lang.NullPointerException
      	at org.mortbay.jetty.HttpParser.isMoreInBuffer(HttpParser.java:161)
      	at org.mortbay.jetty.HttpConnection.handle(HttpConnection.java:437)
      	at org.mortbay.io.nio.SelectChannelEndPoint.run(SelectChannelEndPoint.java:368)
      	at org.mortbay.thread.BoundedThreadPool$PoolThread.run(BoundedThreadPool.java:442)
      

      The last changed rev of HttpParser.java is 1727. We've been taking from the SVN tip to get bug fixes, so my 6.1.2rc label is definitely not a complete description of the state of the source, but it's the SVN head from sometime last week.

      I've seen one instance of this exception in many iterations of the testBufferProblem unit test, but it's worrisome, obviously. We're trying to get a small test case for a problem where we see data from one request show up in the buffer being used for another request.

        Activity

        Hide
        Scott Stanton added a comment -

        I've cloned this issue because I'm still seeing it in 6.1.3, exactly the same stack trace in a different application.

        At the time of the NPE, there is a handler already working on a request in a different thread. The thread that saw the NPE had just completed the response for the previous request. I don't see any failures in other logs that correlate with the NPE, so I'm not sure what request it was about to process. 35 seconds later, the offending thread successfully processes another request.

        This failure is very infrequent. Unfortunately, I don't have a reliable test case.

        Show
        Scott Stanton added a comment - I've cloned this issue because I'm still seeing it in 6.1.3, exactly the same stack trace in a different application. At the time of the NPE, there is a handler already working on a request in a different thread. The thread that saw the NPE had just completed the response for the previous request. I don't see any failures in other logs that correlate with the NPE, so I'm not sure what request it was about to process. 35 seconds later, the offending thread successfully processes another request. This failure is very infrequent. Unfortunately, I don't have a reliable test case.
        Hide
        Greg Wilkins added a comment -

        Scott,

        I have seen NPEs like this when a connection has been closed after a response has been completed. One thread is dispatched to destroy the connection while the other is completing. However, I thought we had fixed this with a delayed destroy.

        I can see how to simply avoid it, by assigning to a local variable before the null and content check. But I will do a bit more analysis first to see if I can see why this race is happening.

        Show
        Greg Wilkins added a comment - Scott, I have seen NPEs like this when a connection has been closed after a response has been completed. One thread is dispatched to destroy the connection while the other is completing. However, I thought we had fixed this with a delayed destroy. I can see how to simply avoid it, by assigning to a local variable before the null and content check. But I will do a bit more analysis first to see if I can see why this race is happening.
        Hide
        Greg Wilkins added a comment -

        I see the problem!
        The call to isMoreInBuffer was left just outside the protection for delayed destruction
        So there was a little tiny minuscule race. It was of no harm other than a noisy end to a request handling.

        I think this is fixed in SVN now... but I have not been able to reproduce so I'm only 99.9% sure

        Show
        Greg Wilkins added a comment - I see the problem! The call to isMoreInBuffer was left just outside the protection for delayed destruction So there was a little tiny minuscule race. It was of no harm other than a noisy end to a request handling. I think this is fixed in SVN now... but I have not been able to reproduce so I'm only 99.9% sure

          People

          • Assignee:
            Greg Wilkins
            Reporter:
            Scott Stanton
          • Votes:
            0 Vote for this issue
            Watchers:
            0 Start watching this issue

            Dates

            • Created:
              Updated:
              Resolved: