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 <[email protected]> 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 <[email protected]> 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 <[email protected]> > > 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 <[email protected]> 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
