Yeah I added allowStreaming=false explicitly to my endpoints now, but I don't think they were running in streaming mode cause I was able to modify the SOAP header Anyways, the problem with the logging level mysteriously seems to be solved, even when I remove the allowStreaming option again.
The weird problem with redeliveryDelay remains, under 5000 I receive <soap:Envelope xmlns:soap="http://schemas.xmlsoap.org/soap/envelope/";> <soap:Body> <soap:Fault> <faultcode>soap:Server</faultcode> <faultstring><![CDATA[Response was of unexpected text/html ContentType. Incoming portion of HTML stream: <soapenv:Envelope xmlns:soapenv="http://schemas.xmlsoap.org/soap/envelope/";> <soapenv:Body> <soapenv:Fault> <faultcode>Server</faultcode> <faultstring>Missing operation for soapAction [] and body element [null] with SOAP Version [SOAP 1.1]</faultstring> </soapenv:Fault> </soapenv:Body> </soapenv:Envelope>]]></faultstring> </soap:Fault> </soap:Body> </soap:Envelope> when talking to a SOAPUI mock service which always returns the same SOAP Fault. From 5000 and above I just get the SOAPFault that is configured in the soapui mock service, which is what I want. Maybe something with SOAPUI and not with Camel? Although making the request directly to the soapui mock from with soapui works when firing multiple requests rapidly. On Mon, Apr 8, 2013 at 3:11 PM, Claus Ibsen <claus.ib...@gmail.com> wrote: > See the bottom of the camel-cxf wiki page, about > > Streaming Support in PAYLOAD mode > > On Mon, Apr 8, 2013 at 3:08 PM, Nico Mommaerts <nico.mommae...@gmail.com> > wrote: > > No I don't think I'm running in streaming mode: > > <camelContext id="camelContext" xmlns=" > http://camel.apache.org/schema/spring"; > > streamCache="false" trace="false"> > > <properties> > > <property key="CamelLogDebugStreams" value="false"/> > > </properties> > > > > <jmxAgent id="agent" disabled="true"/> > > <routeBuilder ref="brokerRouteBuilder" /> > > </camelContext> > > > > On Mon, Apr 8, 2013 at 2:29 PM, Claus Ibsen <claus.ib...@gmail.com> > wrote: > > > >> Hi > >> > >> Sounds like you use camel-cxf / CXF in streaming mode. > >> See the top of this page, the green tip bar, and its link(s) > >> http://camel.apache.org/cxf > >> > >> > >> > >> On Fri, Apr 5, 2013 at 2:33 PM, Nico Mommaerts < > nico.mommae...@gmail.com> > >> wrote: > >> > Hey, > >> > > >> > I've been reading the chapter on Error handling over and over but I'm > >> still > >> > failing miserably.. > >> > > >> > My scenario: a cxf proxy route which modifies the soapheaders, I want > all > >> > soapfaults to be returned as-is to the caller, except when the > soapfault > >> > contains a certain string. In that case I want to modify the > soapheader > >> of > >> > the original message again and redeliver. Modify/redeliver up to x > times, > >> > then just return the soapfault to the caller. > >> > > >> > Given the power of the error handling in Camel this would seem easy. > >> > > >> > This is my route without error handling: > >> > from("cxf:bean:brokerOrderLimit?dataFormat=PAYLOAD") > >> > .process(soapHeadersEnricher) // modfies the soapheader > >> > .to("cxf:bean:backendOrderLimit?dataFormat=PAYLOAD") > >> > > >> > I have: getContext().setHandleFault(true); so SOAPFault gets > recognized > >> as > >> > an exception. > >> > > >> > If I use the doTry()..doCatch(SOAPFault.class).process(//examine > >> > fault).doEnd(), I succeed in recognized the special case I want to > >> handle. > >> > But I have no idea how to control the route flow from that point. I > want > >> to > >> > change the soapheader and redeliver to the endpoint which returned the > >> > soapfault. Right now the caller just gets back an empty soap envelope > >> when > >> > I do this. > >> > > >> > I also tried with > >> > from("cxf:bean:brokerOrderLimit?dataFormat=PAYLOAD") > >> > .process(soapHeadersEnricher) > >> > .to("cxf:bean:thalerOrderLimit?dataFormat=PAYLOAD") > >> > .onException(SoapFault.class) > >> > .onWhen(//filter the special case) > >> > .handled(true); // true or false > doesn't > >> > seem to make a difference, also tried with continued > >> > But in this case the predicate is never even called (so the exception > >> isn't > >> > caught), and the caller just receives the soapfault back. > >> > > >> > Not sure how to handle this problem, any ideas? > >> > >> > >> > >> -- > >> Claus Ibsen > >> ----------------- > >> Red Hat, Inc. > >> FuseSource is now part of Red Hat > >> Email: cib...@redhat.com > >> Web: http://fusesource.com > >> Twitter: davsclaus > >> Blog: http://davsclaus.com > >> Author of Camel in Action: http://www.manning.com/ibsen > >> > > > > -- > Claus Ibsen > ----------------- > Red Hat, Inc. > FuseSource is now part of Red Hat > Email: cib...@redhat.com > Web: http://fusesource.com > Twitter: davsclaus > Blog: http://davsclaus.com > Author of Camel in Action: http://www.manning.com/ibsen >
