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 Wed, 22 Jul 2015 15:24:13 GMT

configuring CXF to be synchronous definitely removes the stack trace, so it does appear to
be an async issue with Jetty.

I sent a message to their list and they nudged me to try jetty 9 to see if it's been fixed.
 However, camel-cxf seems to have a requirement for jetty < 9 and I wasn't able to install
it

Do you know if current snapshot builds for camel-cxf will work with jetty 9?

If not, I will probably sit on this for a while, or see if i can setup straight CXF to do
async calls with jetty 9.

If the issue exists in 9, I will try to sort through it with the jetty group, if it was fixed
in 9, I will leave it up to them to see if they are going to fix 8.

This doesn't really seem to be a show stopper for anyone I'm guessing, else it probably would
have got more attention.

Thanks Claus you do great work!

On Wed, 22 Jul 2015 06:18:47 +0200, Claus Ibsen <claus.ibsen@gmail.com> wrote:

> Hi
> 
> You can configure CXF to be synchronous with ?synchronous=true on the
> camel endpoint uri.
> 
> On Tue, Jul 21, 2015 at 7:54 PM, Ed Welch <ed@edjusted.com> wrote:
> > 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
> >
> >
> 
> 
> 
> -- 
> Claus Ibsen
> -----------------
> http://davsclaus.com @davsclaus
> Camel in Action 2nd edition: http://www.manning.com/ibsen2



Mime
View raw message