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

Reply via email to