This is..frustrating Putting the redeliveryDelay at 5000 solves the Missing operation fault, but I'm talking to a mock soapui service which always return the same response, how can the redeliveryDelay influence this??
To recap: I got redelivery working if I put the loglevel of org.apache.camel.processor.SendProcessor to DEBUG and the redeliveryDelay >= 5000. This can't be right, is Camel so buggy or is my route configuration so wrong? And if it is wrong, why these, very, very strange errors? On Fri, Apr 5, 2013 at 5:09 PM, Nico Mommaerts <nico.mommae...@gmail.com>wrote: > log4j.logger.org.apache.camel.processor.SendProcessor=DEBUG > => some redelivery seems to be happening but still getting errors: > org.apache.cxf.interceptor.Fault: 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> > I can see in SOAPUI in my mockservice that no actual redelivery was made. > > log4j.logger.org.apache.camel.processor.SendProcessor=INFO > => no redelivery happens! Can't see anything in the SendProcessor code > that would cause this though.. > > On Fri, Apr 5, 2013 at 3:55 PM, Nico Mommaerts > <nico.mommae...@gmail.com>wrote: > >> I'm getting nearer: >> >> from("cxf:bean:brokerOrderLimit?dataFormat=PAYLOAD") >> .onException(SoapFault.class) >> .onWhen(thalerLoginExceptionPredicate) >> .handled(true) >> .maximumRedeliveries(3) >> .redeliveryDelay(100) >> .retryAttemptedLogLevel(LoggingLevel.WARN) >> .onRedelivery(new Processor() { >> @Override >> public void process(Exchange exchange) throws Exception { >> AccessKey accessKey = >> exchange.getProperty(ThalerSoapHeadersEnricher.ACCESKEY_PROPERTY, >> AccessKey.class); >> accessKeyProvider.invalidate(accessKey); >> >> CxfPayload<SoapHeader> msg = exchange.getIn().getBody(CxfPayload.class); >> >> AccessKey newKey = accessKeyProvider.borrowAccessKey(); >> System.out.println("insert new key" + newKey); >> } >> }) >> .end() >> .process(soapHeadersEnricher) >> .to("cxf:bean:thalerOrderLimit?dataFormat=PAYLOAD") >> .process(new Processor() { >> @Override >> public void process(Exchange exchange) throws Exception { >> AccessKey accessKey = >> exchange.getProperty(ThalerSoapHeadersEnricher.ACCESKEY_PROPERTY, >> AccessKey.class); >> accessKeyProvider.returnAccessKey(accessKey); >> } >> }); >> >> BUT my current problem is that redelivery only happens when the camel >> log4j log level is on DEBUG! What strange manner of magic is this I ask >> thee? On INFO the exception does get caught but nothing further happens, >> the route seems to be stuck somewhere, eventually Soapui (which I use to >> test) receives a timeout, >> >> >> 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? >>> >>> >> >
