Jetty

java.lang.NullPointerException at org.mortbay.jetty.HttpFields$2.hasNext(HttpFields.java:268)

Details

  • Type: Bug Bug
  • Status: Resolved Resolved
  • Priority: Major Major
  • Resolution: Fixed
  • Affects Version/s: 6.1.2
  • Fix Version/s: 6.1.2
  • Component/s: HTTP
  • Labels:
    None
  • Testcase included:
    yes
  • Number of attachments :
    0

Description

With code from the SVN head as of this morning 4/19/07), we're getting lots of these errors:

2007-04-19T14:34:26.019 | ERROR | btpool0-1     |                                               | log                            | handle failed
java.lang.NullPointerException
	at org.mortbay.jetty.HttpFields$2.hasNext(HttpFields.java:268)
	at org.mortbay.jetty.HttpGenerator.completeHeader(HttpGenerator.java:383)
	at org.mortbay.jetty.HttpConnection.completeResponse(HttpConnection.java:557)
	at org.mortbay.jetty.Response.complete(Response.java:1073)
	at org.mortbay.jetty.HttpConnection.handleRequest(HttpConnection.java:532)
	at org.mortbay.jetty.HttpConnection$RequestHandler.content(HttpConnection.java:806)
	at org.mortbay.jetty.HttpParser.parseNext(HttpParser.java:638)
	at org.mortbay.jetty.HttpParser.parseAvailable(HttpParser.java:208)
	at org.mortbay.jetty.HttpConnection.handle(HttpConnection.java:359)
	at org.mortbay.io.nio.SelectChannelEndPoint.run(SelectChannelEndPoint.java:362)
	at org.mortbay.thread.BoundedThreadPool$PoolThread.run(BoundedThreadPool.java:442)

This happens while running the org.mortbay.jetty.HttpServerTestBase.testRequest2Iterate_jetty test case. The test case fails about 20-30% of the time on Windows and pretty much 100% of the time on Solaris.

Activity

Ascending order - Click to sort in descending order
Hide
Permalink
Anders Wallgren added a comment -

When the test fails, we also see this in the logs:

2007-04-19T14:51:40.265 | ERROR | btpool0-3     |                                               | log                            | handle failed
java.lang.IllegalStateException: response
	at org.mortbay.jetty.HttpConnection$RequestHandler.startResponse(HttpConnection.java:827)
	at org.mortbay.jetty.HttpParser.parseNext(HttpParser.java:399)
	at org.mortbay.jetty.HttpParser.parseAvailable(HttpParser.java:202)
	at org.mortbay.jetty.HttpConnection.handle(HttpConnection.java:359)
	at org.mortbay.io.nio.SelectChannelEndPoint.run(SelectChannelEndPoint.java:362)
	at org.mortbay.thread.BoundedThreadPool$PoolThread.run(BoundedThreadPool.java:442)
Show
Anders Wallgren added a comment - When the test fails, we also see this in the logs: 2007-04-19T14:51:40.265 | ERROR | btpool0-3 | | log | handle failed java.lang.IllegalStateException: response at org.mortbay.jetty.HttpConnection$RequestHandler.startResponse(HttpConnection.java:827) at org.mortbay.jetty.HttpParser.parseNext(HttpParser.java:399) at org.mortbay.jetty.HttpParser.parseAvailable(HttpParser.java:202) at org.mortbay.jetty.HttpConnection.handle(HttpConnection.java:359) at org.mortbay.io.nio.SelectChannelEndPoint.run(SelectChannelEndPoint.java:362) at org.mortbay.thread.BoundedThreadPool$PoolThread.run(BoundedThreadPool.java:442)
Hide
Permalink
Greg Wilkins added a comment -

Can you report the actual repository version that you are upto?
I'm on 1768 and can't see this problem on linux.

Show
Greg Wilkins added a comment - Can you report the actual repository version that you are upto? I'm on 1768 and can't see this problem on linux.
Hide
Permalink
Greg Wilkins added a comment -

Something very strange is happening! The second exception indicates that a response was sent as a request!
I've updated the code to simply respond with a 400 bad request.... but I'd still like to know what is a happening.

the first exception is probably due to a connection being closed while the test is running....
so it is not a nasty nasty exception.... but one that I do need to deal with.

But more importantly, I'd like to know WHY this test harness is failing for you?

Show
Greg Wilkins added a comment - Something very strange is happening! The second exception indicates that a response was sent as a request! I've updated the code to simply respond with a 400 bad request.... but I'd still like to know what is a happening. the first exception is probably due to a connection being closed while the test is running.... so it is not a nasty nasty exception.... but one that I do need to deal with. But more importantly, I'd like to know WHY this test harness is failing for you?
Hide
Permalink
Anders Wallgren added a comment -

This revision:

C:\java\jetty>svn info
Path: .
URL: https://svn.codehaus.org/jetty/jetty/trunk
Repository Root: https://svn.codehaus.org/jetty
Repository UUID: c7fae8f8-2506-0410-b6b2-ad6cf81c2737
Revision: 1766
Node Kind: directory
Schedule: normal
Last Changed Author: gregw
Last Changed Rev: 1763
Last Changed Date: 2007-04-19 02:09:33 -0700 (Thu, 19 Apr 2007)

We're seeing the problem on windows and solaris – haven't on linux so far, but I'm not sure why.

Show
Anders Wallgren added a comment - This revision: C:\java\jetty>svn info Path: . URL: https: //svn.codehaus.org/jetty/jetty/trunk Repository Root: https: //svn.codehaus.org/jetty Repository UUID: c7fae8f8-2506-0410-b6b2-ad6cf81c2737 Revision: 1766 Node Kind: directory Schedule: normal Last Changed Author: gregw Last Changed Rev: 1763 Last Changed Date: 2007-04-19 02:09:33 -0700 (Thu, 19 Apr 2007) We're seeing the problem on windows and solaris – haven't on linux so far, but I'm not sure why.
Hide
Permalink
Anders Wallgren added a comment -

Also, all our machines (solaris/windows/linux) are multi-core, in case that matters.

Show
Anders Wallgren added a comment - Also, all our machines (solaris/windows/linux) are multi-core, in case that matters.
Hide
Permalink
Greg Wilkins added a comment -

Thanks - my machine is a multi core as well.... so strange it is not happening on linux?

I think I know what has caused this... removing the synchronize on endpoint.run.
But that was causing a nasty delay in a moderately rare, but likely enough use-case.

OK thinking hat on to see if I can devise a solution that is not horribly expensive with
regards to locking.... Are you online for much longer?

Show
Greg Wilkins added a comment - Thanks - my machine is a multi core as well.... so strange it is not happening on linux? I think I know what has caused this... removing the synchronize on endpoint.run. But that was causing a nasty delay in a moderately rare, but likely enough use-case. OK thinking hat on to see if I can devise a solution that is not horribly expensive with regards to locking.... Are you online for much longer?
Hide
Permalink
Anders Wallgren added a comment -

I'll be around for the next several hours.

Show
Anders Wallgren added a comment - I'll be around for the next several hours.
Hide
Permalink
Greg Wilkins added a comment -

I believe I have fixed this.

I have eased the sync on connection.handle
so that connection.destroy can be delayed if there is a handle
outstanding.

To cope with this, I had to be more rigorous with the scheduling
of continuations, which had just allowed multiple dispatches
if an expire collided with a resume (and all was sorted out later).

I'd appreciate any feedback you can give

Show
Greg Wilkins added a comment - I believe I have fixed this. I have eased the sync on connection.handle so that connection.destroy can be delayed if there is a handle outstanding. To cope with this, I had to be more rigorous with the scheduling of continuations, which had just allowed multiple dispatches if an expire collided with a resume (and all was sorted out later). I'd appreciate any feedback you can give
Hide
Permalink
Anders Wallgren added a comment -

The unit test passes, so that's good news. I've kicked off a preflight build to run the full suite of tests.

Show
Anders Wallgren added a comment - The unit test passes, so that's good news. I've kicked off a preflight build to run the full suite of tests.

People

  • Assignee:
    Unassigned
    Reporter:
    Anders Wallgren
Vote (0)
Watch (2)

Dates

  • Created:
    Updated:
    Resolved: