Hi,
You are right with your assumption.
Here is the code snippet in the DeadLetterChannel to prove your assumption.
// did previous processing caused an exception?
if (exchange.getException() != null) {
handleException(exchange, data);
}
// compute if we should redeliver or not
boolean shouldRedeliver = shouldRedeliver(exchange, data);
if (!shouldRedeliver) {
deliverToFaultProcessor(exchange, callback, data);
return;
}
Since you set the maximumRedeliveries(1), the exchange will be
redelivered again, then pass to the fault processor which you use for
changing your fault message state.
If you just want to change the state of your fault message, could add a
MyFaultInterceptor yourself like this.
from("jms:queue:memoReadyToProcess").intercept(new MyFaultInterceptor())
.process(new MemoCreationProcessor());
MyFaultInterceptor could be like this
public class MyFaultInterceptor extends Interceptor {
public MyFaultInterceptor() {
super();
setInterceptorLogic(new Processor() {
public void process(Exchange exchange) throws Exception {
try {
proceed(exchange);
} catch (TheExceptionYouWant ex) {
// change the state of your fail Message here
// then throw the exception out again
throw ex;
}
}
});
}
...
}
Willem
dougly wrote:
> Hi guys,
> I declare a exception handling for one of my route. If the exception occurs,
> I'd like to change the state of that failed message and do a re-delivery. So
> far I have my route built like this
>
> public void configure() throws Exception
> {
> onException(MemoException.class)
> .maximumRedeliveries(1)
> .handled(true)
> // increase retry count
> .transform().body()
> .process(new Processor() {
>
> @Override
> public void process(Exchange exchange) throws Exception
> {
> ShortMessage shortMessage =
> exchange.getIn().getBody(ShortMessage.class);
> shortMessage.increaseRetryCount();
> }
>
> });
>
> from("jms:queue:memoReadyToProcess")
> .process(new MemoCreationProcessor());
> }
>
> Weird thing is even my MemoCreationProcessor did receive the second retry
> message, that message state was not changed (not called 'increaseRetryCount"
> above).
> The message state on ly changed after the redelivery failed.
>
> So the work flow here as I understand is:
>
> Calling MemoCreationProcessor -> failed -> calling MemoCreationProcessor
> again -> failed -> calling exception handling -> changed message state
>
> Is my assumption correct? If that's the case and I need to change state of
> my failed message, how could I do it?
>
> Thanks a bunch riders,
>
> Doug
