Ed, In general, jetty-8 is now superceded by jetty-9, which has a different implementation a lot of the handling code and is being actively developed whilst jetty-8 is not, and only has very sporadic releases. So my first recommendation is to upgrade to jetty-9, but I guess you are getting your jetty via one of your dependencies and thus not able to upgrade?
If you have some references for the places in the camel code that is doing the async handling that might give us some clues as to what might be happening? It's a little difficult to understand the sequence of events from the description from a jetty point-of-view .... some more logs and stack traces around the request handling might make things clearer too. regards, Jan On 22 July 2015 at 04:35, Ed Welch <[email protected]> wrote: > Hello, > > Not sure how to best summarize where I am and how I got here, but I'll > give it a go. > > Seeing some undesirable behavior with a specific combination of > libraries/frameworks in an OSGi environment (running Jetty 8.1.15v20140411). > > Managed to track down what I am seeing to some code in > org.eclipse.jetty.server.handler.ContextHandler which has me suspicous: > > switch (_availability) > { > case __STOPPED: > case __SHUTDOWN: > return false; > case __UNAVAILABLE: > baseRequest.setHandled(true); > > response.sendError(HttpServletResponse.SC_SERVICE_UNAVAILABLE); > return false; > default: > if ((DispatcherType.REQUEST.equals(dispatch) && > baseRequest.isHandled())) > return false; > } > > > So what's happening: > > when using camel-cxf 2.15.2 in karaf 3.0.3 with jolokia-osgi bundle > installed, calls to my SOAP webservice provided by camel-cxf result in the > jolokia (which is an unrelated jmx->http converter) handler being called > after the response to my webservice call is already received by the > client. This results in a stack trace in the logs: > > > 2015-07-18 14:37:03,379 | WARN | qtp23458725-67 | Response | 71 - > org.eclipse.jetty.aggregate.jetty-all-server - 8.1.15.v20140411 | Committed > before 401 null > 2015-07-18 14:37:03,379 | WARN | qtp23458725-67 | > AbstractHttpConnection | 71 - org.eclipse.jetty.aggregate.jetty-all-server > - 8.1.15.v20140411 | /cxf/test/ > java.lang.IllegalStateException: Committed > at > org.eclipse.jetty.server.Response.resetBuffer(Response.java:1154)[71:org.eclipse.jetty.aggregate.jetty-all-server:8.1.15.v20140411] > at > org.eclipse.jetty.server.Response.sendError(Response.java:317)[71:org.eclipse.jetty.aggregate.jetty-all-server:8.1.15.v20140411] > at > org.eclipse.jetty.server.Response.sendError(Response.java:419)[71:org.eclipse.jetty.aggregate.jetty-all-server:8.1.15.v20140411] > at > javax.servlet.http.HttpServletResponseWrapper.sendError(HttpServletResponseWrapper.java:137)[65:org.apache.geronimo.specs.geronimo-servlet_3.0_spec:1.0.0] > at > org.jolokia.osgi.security.BasicAuthenticationHttpContext.handleSecurity(BasicAuthenticationHttpContext.java:49)[144:org.jolokia.osgi:1.3.1] > at > org.ops4j.pax.web.service.jetty.internal.HttpServiceServletHandler.doHandle(HttpServiceServletHandler.java:68)[80:org.ops4j.pax.web.pax-web-jetty:3.1.4] > at > org.eclipse.jetty.server.handler.ScopedHandler.handle(ScopedHandler.java:137)[71:org.eclipse.jetty.aggregate.jetty-all-server:8.1.15.v20140411] > ... > > The full stack is in the link to the pax-web ticket below. > > Stepping through with the debugger, it appears camel-cxf is doing some > ASYNC response handling for this webservice call, and what appears to > happen is for the REQUEST part of the call, that block of code I pasted > above gets hit for all the handlers, and they all return false because the > DispatcherType.REQUEST == REQUEST and isHandled() == true. > > However, when the ASYNC part is handled, we enter into the same code > block, however, the DispatcherType is ASYNC causing that conditional to be > false, and the request to continue to be handled, EVEN THOUGH isHandled() > is == true. > > I'm wondering if that default case should be expanded to include > DispatcherType.REQUST AND DispatcherType.ASYNC? > > Ultimately the error shows up in the logs because jolokia is registering a > DefaultHttpContext which overrides the handleSecurity method, and calls > HttpServletResponse's sendError method if it can't authenticate the > request, but in my opinion I don't think this code should ever be called at > all. > > Through the course of trying to track down the cause of this issue, i had > created a ticket with the pax-web group, it has a more detailed summary of > how I got here: https://ops4j1.jira.com/browse/PAXWEB-863 > > Additionally, I created a sample project to reproduce the issue: > https://github.com/erwelch/paxweb-863 (where installing the > edjusted-karaf-feature-camel feature will demonstrate this issue) > > Thoughts? > > Thanks, > Ed > _______________________________________________ > 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
