Skip to main content
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: [jetty-users] Question about ASYNC DispatcherType and handlers
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 <ed@xxxxxxxxxxxx> 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
jetty-users@xxxxxxxxxxx
To change your delivery options, retrieve your password, or unsubscribe from this list, visit
https://dev.eclipse.org/mailman/listinfo/jetty-users

Back to the top