Skip to main content

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
[jetty-users] Question about ASYNC DispatcherType and handlers

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

Back to the top