Jetty

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

Ascending order - Click to sort in descending order
Hide
Permalink
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
Permalink
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
Permalink
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
Vote (0)
Watch (0)

Dates

  • Created:
    Updated:
    Resolved: