Details
-
Type:
Bug
-
Status:
Resolved
-
Priority:
Major
-
Resolution: Cannot Reproduce
-
Affects Version/s: 6.1.21, 6.1.26, 7.3.1
-
Fix Version/s: None
-
Component/s: HTTP
-
Labels:None
-
Environment:Ubuntu 10.04.2 x86_64
-
Source ID:
-
Number of attachments :
Description
We're seing a number of these stacktraces in our logs, seen with Jetty
6.1.21, 6.1.26 and 7.3.1v20110307:
HTTP/1.1 21.02.2011 14:59:04.892 WARN [446583619@qtp-904935057-66]
org.apache.felix.http.jetty handle failed
(java.lang.IllegalStateException: STATE!=START)
java.lang.IllegalStateException: STATE!=START
at
org.mortbay.jetty.AbstractGenerator.setVersion(AbstractGenerator.java:319)
at
org.mortbay.jetty.HttpConnection$RequestHandler.headerComplete(HttpConnection.java:859)
at org.mortbay.jetty.HttpParser.parseNext(HttpParser.java:539)
at org.mortbay.jetty.HttpParser.parseAvailable(HttpParser.java:212)
at org.mortbay.jetty.HttpConnection.handle(HttpConnection.java:405)
at
org.mortbay.io.nio.SelectChannelEndPoint.run(SelectChannelEndPoint.java:409)
at
org.mortbay.thread.QueuedThreadPool$PoolThread.run(QueuedThreadPool.java:582)
This is the full stacktrace, as you can see, the only code involved
here is Jetty code.
This happens on about 1% of the requests, and causes the request to
fail with a 503.
We're only seeing this in production, and the problem seems to occur
completely randomly, so we haven't ben able to debug the problem
properly.
But we have added some debug output, and found that when this
situation occurs, o.m.j.AbstractGenerator._state is not properly reset
from the previous request on the same connection. This causes the if
(_state != STATE_HEADER) test in setVersion to return false, thus
throwing the IllegalStateException.
The previous request, however, has been returned correctly with a 200 OK.
This LOOKS as though it could be related to JETTY-743, but that one has been closed as "Not a bug".