[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
Re: [jetty-dev] 8.1.2.v20120308 - rare mixup of requests
|
Well the problem seems to be in Jetty code but very close to the
"border" between Jetty and JVM/OS, so I just want to mention that we run
on Java HotSpot 1.6.0_26 on Ubuntu 10.04.2 LTS.
Reporting from Linux:
Linux xxxxxxx 2.6.32-29-server #58-Ubuntu SMP Fri Feb 11 21:06:51 UTC 2011 x86_64 GNU/Linux
Ubuntu 10.04.2 LTS
Version reporting from Java:
java version "1.6.0_26"
Java(TM) SE Runtime Environment (build 1.6.0_26-b03)
Java HotSpot(TM) 64-Bit Server VM (build 20.1-b02, mixed mode)
Regards, Per Steffensen
Per Steffensen skrev:
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
_______________________________________________
jetty-dev mailing list
jetty-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/jetty-dev