[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
[jetty-dev] 8.1.2.v20120308 - rare mixup of requests
|
Hi
I have found a bug in Jetty 8.1.2.v20120308.
Running with many concurrent clients sending requests to Solr (web-app
running on top of Jetty) sometimes (very rarely) the content of the HTTP
requests are mixed up when handed over by Jetty as
HttpServletRequest-objects to the doFilter method of a
javax.servlet.Filter configured in web.xml. When "hacking"
org.eclipse.jetty.io.bio.StreamEndPoint to log something about what is
actually received over the wire, requests does not seem to be mixed up
"yet". So it is something that goes wrong in Jetty somewhere between
receiving the data over sockets and handing the (parsed) request over to
a filter (or servlet, probably) as a HttpServletRequest.
A little about what I mean with "mixed up":
* Data in request A: abcdefghijklmnopqrstuvwxyz
* Data in request B: 1234567890987654321
Well the requests are longer in my concrete cases, and thats probably
important, but not when just trying to illustrate
Data read by consecutive "fill"-calls in
org.eclipse.jetty.io.bio.StreamEndPoint - e.g:
Regarding request A:
* abcdefghij
* klmnopqrstu
* vwxyz
Regarding request B:
* 12345678909876
* 54321
Seems ok
Data "behind" HttpServletRequest-object handed over to filter/servlet:
Request A: abcdefghijklmnopqrstuvw345678909876
WUT!!!!
Closer investigations show that it is "always" (well I do not have much
statistical material) the last part of the data read in the last
"fill"-call by the "first request" (request A in this example) that is
"magically" replaced by something from a "later request" (request B in
this example) when the data reaches the filter/servlet. And that the
size of the correct part of the data read in the last "fill"-call by
request A is equal to the size of data read in the "violating"
"fill"-call (request B) which is before the data the gets mixed from
request B into request A. Never mind if you didnt understand (I almost
did not :-) ) - let me illustrate by example. E.g. lets say (as the
example above also suggests) that it is the last "fill"-call regarding
request A that gets mixed up with data from the first "fill"-call
regarding request B. The "end result" seen in request A can be:
* abcdefghijklmnopqrstuv2345678909876
* abcdefghijklmnopqrstuvw345678909876
* abcdefghijklmnopqrstuvwx45678909876
* abcdefghijklmnopqrstuvwxy5678909876
But not e.g.
* abcdefghijklmnopqrstuvw5678909876
To me it really seems like org.eclipse.jetty.io.bio.StreamEndPoint reuse
(/share) byte-arrays among requests, and that a byte-array used by
request A will be "released" for usage by request B before request A has
finished reading from it - maybe org.eclipse.jetty.io.bio.StreamEndPoint
is finished using the byte-array for request A stuff, but layers higher
in Jetty might not have ready from the byte-array yet to get the data
for the request-A-HttpServletRequest-object. But what do I know?
I can deepen the explanation and I can provide more "evidence" or
details about exactly how I revealed this bug. But first of all I just
want to know:
* Is this a known bug?
* Has it been fixed?
Regards, Per Steffensen