camel-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Ed Welch" ...@edjusted.com>
Subject Re: Problem with camel-cxf when Jolokia is installed
Date Tue, 21 Jul 2015 17:54:56 GMT
Thanks Claus,

You got the wheels turning a little, and I spent some more time with the debugger.

I have found a section of Jetty code of interest, and I'm going to reach out to their mailing
list to see what they think.

I documented in a little more detail in the running pax-web issue i opened if you are curious:
 https://ops4j1.jira.com/browse/PAXWEB-863?focusedCommentId=28843&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-28843

In summary, it appears the camel-cxf component is doing some ASYNC processing with jetty,
and I'm suspicious that Jetty has a conditional that should also be looking for ASYNC request
types when checking to see if a request has already been handled by another handler.

The plain cxf example I created does not appear to do any ASYNC operations, which is why it's
not seeing this issue.

Will post back for posterity if I make progress with Jetty

On Mon, 20 Jul 2015 21:46:44 +0200, Claus Ibsen <claus.ibsen@gmail.com> wrote:

> Hi
> 
> I have seen those errors to on fabric8 v1. It was when using servlet
> sendError that caused that bug/issue with jetty. Instead you would
> have to build the reply message normally and set status code to an
> error code, then it worked - eg do not use the sendError method on the
> servlet api.
> 
> I wonder if that is what Jolokia does at
> BasicAuthenticationHttpContext. And if so maybe that code can be
> changed.
> 
> On Sat, Jul 18, 2015 at 8:58 PM, Ed Welch <ed@edjusted.com> wrote:
> > I've been trying to get to the bottom of this for a couple weeks now, and I'm stuck....
> >
> > I'll try to keep things as short as possible, but basically, I have a soap webservice
created with the camel cxf component, running in karaf 3.0.3, java 8 update 25, camel 2.15.2,
cxf 3.0.4 (simple sample project linked at the end)
> >
> > And if the jolokia-osgi bundle is installed, every call to my webservice results
in a rather nasty stack trace in the log file:
> >
> > 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]
> > ...
> >
> > I abbreviated the trace, the full stack can be found in the jira link further down,
but you can see in the stack it's trying to call the org.jolokia.osgi.security.BasicAuthenticationHttpContext,
which is bizzare
> >
> > Ok, so first thing to mention, the webservice call works fine, and works fine every
time, the error in the logs occurs after the client receives a successful response
> >
> > At first I thought this was an issue with pax-web, so I opened a ticket over there:
> >
> > https://ops4j1.jira.com/browse/PAXWEB-863
> >
> > Achim very nicely spent some time looking into this, and has not been able to find
any issues with the pax-web code.
> >
> > So out of curiosity, I setup a straight CXF soap webservice in the same environment,
and it works great, no errors even when jolokia is installed.
> >
> > This has lead me over to camel, or how camel is using CXF
> >
> > I've spent a few hours with the debugger but I'm really not getting anywhere, everything
looks to me like jetty is processing the call through camel/cxf as it should, and then a second
process is made to through the context jolokia registers when its installed, and this results
in the error (because the jolokia context looks for the Authorization header, doesn't see
it, throws an exception back to the client, but the connection to the client is already closed
because it was handled and closed in the successful camel call)
> >
> > But this second call stack is mostly jetty and some pax-web classes.  So it doesn't
look like camel code is directly causing this.
> >
> > Some of my thoughts are how the webservice is registered with cxf and in turn with
pax/jetty in the osgi environment, or maybe there is some kind of missing "handled" notification
to jetty to keep it from sending he request to more contexts?  I dunno if that second thing
is real or not, just thinking outloud.
> >
> > I made a sample project to make this easier to test:  https://github.com/erwelch/paxweb-863
> >
> > I'm afraid I'm at a loss for how to further debug this, I'm not convinced this is
a camel issue, but since it's the case I can only re-create this using camel, I'm hoping someone
can help!
> >
> > Thanks,
> > Ed
> 
> 
> 
> -- 
> Claus Ibsen
> -----------------
> http://davsclaus.com @davsclaus
> Camel in Action 2nd edition: http://www.manning.com/ibsen2



Mime
View raw message