Jetty 8 entered EOL (End of Life) over a year ago now. Plenty of changes since then.
(Each of the below is considered a major version release by Jetty) Jetty 9.0 (interim release between Servlet 3.0 and Servlet 3.1) Jetty 9.1 (Final Servlet 3.1, Added JSR-356 Support) Jetty 9.2 (Large refactor of internal Threading, finalize Java 8 support) Jetty 9.3 (Drop SPDY, promote HTTP/2, Java 8 minimum requirement) Jetty [master] is version 9.4 (no release yet) Since Jetty 8.1.8, there have been (up to version 9.3.6) .. - 4 Major version releases of stable Jetty - 70 Minor version releases of stable Jetty - 9,701 commits - 8,919 unique files modified - 5,572 files deleted - 480,773 lines of code changed (excluding deleted files) The Request Object alone has had 1,736 modifications across 149 commits in that same time period. Please try your analysis with something a bit more recent. Try Jetty 9.2.14.v20151106 (if stuck on the EOL Java 7) or use Jetty 9.3.6.v20151106 (if you are using Java 8 already) Joakim Erdfelt / [email protected] On Fri, Dec 18, 2015 at 4:39 AM, Dirk Olmes <[email protected]> wrote: > Hello everyone, > > under moderate load sometimes request parameters are missing from GET > requests. Here are my findings so far: > > An instance of org.eclipse.jetty.server.AbstractHttpConnection keeps a > single instance of the Request - it does not create new Request objects > for each request-response loop it processes. At the end of a > request-response loop the recycle() method is called on the Request > object resetting its internal state. > > In org.eclipse.jetty.server.Request, the _paramsExtracted instance > variable keeps track if the parameters need to be parsed or if that has > been done already. I have put additional logging into the Request object > to observe its behaviour. The typical set of method calls looks like this: > > [qtp25126016-38] DEBUG: *** 13723614 setMethod GET > [qtp25126016-38] DEBUG: *** 13723614 entering getParameterMap > _paramsExtracted is false > [qtp25126016-38] DEBUG: *** 13723614 enter extractParameters > [qtp25126016-38] DEBUG: *** 13723614 setting _paramsExtracted to true: true > [qtp25126016-38] DEBUG: *** 13723614 parameters at end of > extractParameters: {renderer=html, device=screen, _=1450430929102} > [qtp25126016-38] DEBUG: *** 13723614 entering getParameterNames > _paramsExtracted is true > [qtp25126016-38] DEBUG: *** 13723614 entering getParameter(String) > _paramsExtracted is true > [qtp25126016-38] DEBUG: *** 13723614 entering getParameter(String) > _paramsExtracted is true > [qtp25126016-38] DEBUG: *** 13723614 entering getParameter(String) > _paramsExtracted is true > [qtp25126016-38] DEBUG: *** 13723614 recycle _paramsExtracted :false > > Note that I'm using the setMethod() call as the beginning of a > request-response loop and the call to recycle() as the end. The > "13723614" is the integer value of System.identityHashCode() of the > request object. > > As the load on our app increases, we sometimes see the Request object > change for the same thread: > > 2015-12-18 10:30:37.135 [qtp25126016-39] DEBUG: *** 3358385 setMethod POST > 2015-12-18 10:30:37.135 [qtp25126016-39] DEBUG: new RequestDataImpl@16c6c9e > 2015-12-18 10:30:37.135 [qtp25126016-39] DEBUG: putting sessionId -> > 1qz7t24ss14bj1gq3jvbpb2ay6 > 2015-12-18 10:30:37.135 [qtp25126016-39] DEBUG: putting X-Forwarded-For > -> 192.168.21.112 > 2015-12-18 10:30:37.135 [qtp25126016-39] DEBUG: *** 3358385 entering > getParameter(String) _paramsExtracted is false > 2015-12-18 10:30:37.135 [qtp25126016-39] DEBUG: *** 3358385 enter > extractParameters > 2015-12-18 10:30:37.135 [qtp25126016-39] DEBUG: *** 3358385 setting > _paramsExtracted to true: true > 2015-12-18 10:30:37.136 [qtp25126016-39] DEBUG: *** 3358385 parameters > at end of extractParameters: {compound=[xxx]} > 2015-12-18 10:30:37.136 [qtp25126016-39] DEBUG: *** 3358385 entering > getParameter(String) _paramsExtracted is true > 2015-12-18 10:30:37.136 [qtp25126016-39] DEBUG: *** 3358385 entering > getParameter(String) _paramsExtracted is true > 2015-12-18 10:30:37.136 [qtp25126016-39] DEBUG: putting cookie.username > -> xxx > 2015-12-18 10:30:37.136 [qtp25126016-39] DEBUG: putting > cookie.7b8c8f99-c403-4e60-8871-62a2a9288f07 -> > 3a5e8e9f-08b4-4f0b-a0b8-4977c9f8b87f > 2015-12-18 10:30:37.136 [qtp25126016-39] DEBUG: POST: > -------------------------------------------------- > 2015-12-18 10:30:37.136 [qtp25126016-39] DEBUG: POST: > /pid3/ajax;jsessionid=1qz7t24ss14bj1gq3jvbpb2ay6 > 2015-12-18 10:30:37.137 [qtp25126016-39] DEBUG: *** 3358385 entering > getParameterMap _paramsExtracted is true > 2015-12-18 10:30:37.137 [qtp25126016-39] DEBUG: *** 3358385 entering > getParameterNames _paramsExtracted is true > 2015-12-18 10:30:37.137 [qtp25126016-39] DEBUG: POST Parameter: compound > -> [xxx] > 2015-12-18 10:30:37.137 [qtp25126016-39] DEBUG: POST: > -------------------------------------------------- > 2015-12-18 10:30:37.137 [qtp25126016-39] DEBUG: *** 3358385 entering > getParameterNames _paramsExtracted is true > 2015-12-18 10:30:37.137 [qtp25126016-39] DEBUG: *** 3358385 entering > getParameterNames _paramsExtracted is true > 2015-12-18 10:30:37.454 [qtp25126016-39] DEBUG: *** 13723614 entering > getParameter(String) _paramsExtracted is false > 2015-12-18 10:30:37.454 [qtp25126016-39] DEBUG: *** 13723614 enter > extractParameters > 2015-12-18 10:30:37.454 [qtp25126016-39] DEBUG: *** 13723614 setting > _paramsExtracted to true: true > 2015-12-18 10:30:37.454 [qtp25126016-39] DEBUG: *** 13723614 parameters > at end of extractParameters: {} > 2015-12-18 10:30:37.456 [qtp25126016-39] DEBUG: *** 3358385 entering > getParameter(String) _paramsExtracted is true > 2015-12-18 10:30:37.457 [qtp25126016-39] DEBUG: *** 3358385 recycle > _paramsExtracted :false > > Again, the lines marked with *** are the added debug output in the > Request object. I have added the thread name as the second info in each > line after the date. Note that while the thread stays the same, the > Request object changes in the last 3 lines. > > Maybe I should also mention our environment: > - Linux 64 bit > - JDK 8u51 > - Jetty 8.1.8.v20121106 - I know it's old. But I can reproduce the error > with Jetty 8.1.18.v20150929, too. As we configure Jetty from code, an > update to Jetty 9 is not an option right now :-( > - Right now we're using SelectChannelConnector that's default in the > Jetty Server class. But I can reproduce the bug using SocketConnector as > well. > > This is as far as my analysis gets. I was hoping that someone on this > list may come up with suggestions or hints on how to analyze this further. > > -dirk > _______________________________________________ > jetty-users mailing list > [email protected] > To change your delivery options, retrieve your password, or unsubscribe > from this list, visit > https://dev.eclipse.org/mailman/listinfo/jetty-users >
_______________________________________________ jetty-users mailing list [email protected] To change your delivery options, retrieve your password, or unsubscribe from this list, visit https://dev.eclipse.org/mailman/listinfo/jetty-users
