Skip to main content

[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


Back to the top