Error Channel Behavior

[cjd11]

We are deploying a spring component that uses Spring Integration in JBoss. We have resitered an error channel and error listener.
When we undeploy a war file, Jboss classloading seems to unload a logger class and cause an NPE to be thrown and this gets picked up on the MessagePublishingErrorHandler. Trying to log the message causes another exception that gets caugth etc.
This is an easy error to reporduce - the thread that the error listener runs in cannot throw exception without taking us on a never ending loop (until we terminate the VM).

We need a solution to this issue.
Thanks,
Caroline.

[cjd11]

THis error is tied into the deploy/undeploy error in a separate thread.

Thanks,
Caroline.

[Mark Fisher]

Caroline,

Is the MessageHandler referenced by the endpoint that is subscribed to the 'errorChannel' an implementation of the MessageHandler interface, or is it delegating to a simple Object (or using annotations)?

If it is an actual MessageHandler implementation, can you try/catch *any* exception within it's handle method? (maybe just print the stack trace for now). If I understand the problem correctly, then we need to always set a no-op (not even logging) errorHandler on any handler that is itself subscribed to the 'errorChannel'?

Thanks,
-Mark

[cjd11]

Mark,
here is the configuration that we use:

<endpoint input-channel="errorChannel"
default-output-channel="outputChannel"
handler-ref="errorListener"
handler-method="handle"/>

<beans:bean id="errorListener" class="com.wachovia.cib.gfits.integration.handler.error.E rrorListener"/>

Our error listener has a set of observers that it passes the error to.

Fairly simple stuff.

So if you skip the observer step - and throw a RTE in teh listener - you should be able to reproduce this behavior.

Thanks,
Caroline.

[Mark Fisher]

Thank you Caroline.

I am about to commit a change that breaks the endless loop for an error thrown in an error handler. I'll first see if I can reproduce with this same scenario.

Thanks,
Mark

[Mark Fisher]

Caroline,

I have committed a change in the MessageBus such that the MessagePublishingErrorHandler is not set as the default 'errorHandler' for any listener on the "errorChannel".

Note that the errors will be logged, but not sent back to the error channel. So you should only see warn-level logging for an error thrown from the handler that is listening to the errorChannel.

This change is available on the SVN HEAD and will be in tonight's snapshot. If you get a chance to test it please let me know if your problem is resolved.

Also, as a short term solution, you should be able to add the "error-handler" attribute to your <endpoint/> and provide a reference to a bean that implements ErrorHandler as a no-op or only logs. For example:


<endpoint input-channel="errorChannel"
default-output-channel="outputChannel"
handler-ref="errorListener"
handler-method="handle"
error-handler="loggingOnlyErrorHandler/>


Thanks,
Mark

[cjd11]

Hey Mark,
I have repeated my test case with the snapshot release that you referenced; I did not setthe error channel to be purely logging, as that is not hte behavior we need. It looks as though the endless loop is broken, with a retry limit of 5 - this is the final exception I see:
T ERROR ........ with 2XXXCC for Method 'onMessage' threw an Exception.class or
g.springframework.integration.message.MessagingExc eption
05:31:39,844 WARN [MessagePublishingErrorHandler](pool-1-thread-1:) failure occ
urred in messaging task
org.springframework.integration.message.MessageDel iveryException: Dispatcher rea
ched rejection limit of 5. Consider increasing the handler's concurrency and/or
the dispatcherPolicy's 'rejectionLimit'.
at org.springframework.integration.dispatcher.Default MessageDistributor.
distribute(DefaultMessageDistributor.java:122)
at org.springframework.integration.dispatcher.Default MessageDispatcher.d
oDispatch(DefaultMessageDispatcher.java:183)
at org.springframework.integration.dispatcher.Default MessageDispatcher.a
ccess$2(DefaultMessageDispatcher.java:176)
at org.springframework.integration.dispatcher.Default MessageDispatcher$D
ispatcherTask.run(DefaultMessageDispatcher.java:21 7)
at org.springframework.integration.scheduling.SimpleM essagingTaskSchedul
er$MessagingTaskRunner.run(SimpleMessagingTaskSche duler.java:136)
at java.util.concurrent.Executors$RunnableAdapter.cal l(Executors.java:41
7)
at java.util.concurrent.FutureTask$Sync.innerRunAndRe set(FutureTask.java
:280)
at java.util.concurrent.FutureTask.runAndReset(Future Task.java:135)
at java.util.concurrent.ScheduledThreadPoolExecutor$S cheduledFutureTask.
access$101(ScheduledThreadPoolExecutor.java:65)
at java.util.concurrent.ScheduledThreadPoolExecutor$S cheduledFutureTask.
runPeriodic(ScheduledThreadPoolExecutor.java:142)
at java.util.concurrent.ScheduledThreadPoolExecutor$S cheduledFutureTask.
run(ScheduledThreadPoolExecutor.java:166)
at java.util.concurrent.ThreadPoolExecutor$Worker.run Task(ThreadPoolExec
utor.java:650)
at java.util.concurrent.ThreadPoolExecutor$Worker.run (ThreadPoolExecutor
.java:675)
at java.lang.Thread.run(Thread.java:595)

[cjd11]

Hey Mark,
I have repeated my test case with the snapshot release that you referenced; I did not setthe error channel to be purely logging, as that is not hte behavior we need. It looks as though the endless loop is broken, with a retry limit of 5 - this is the final exception I see:
T ERROR ........ with 2XXXCC for Method 'onMessage' threw an Exception.class or
g.springframework.integration.message.MessagingExc eption
05:31:39,844 WARN [MessagePublishingErrorHandler](pool-1-thread-1:) failure occ
urred in messaging task
org.springframework.integration.message.MessageDel iveryException: Dispatcher rea
ched rejection limit of 5. Consider increasing the handler's concurrency and/or
the dispatcherPolicy's 'rejectionLimit'.
at org.springframework.integration.dispatcher.Default MessageDistributor.
distribute(DefaultMessageDistributor.java:122)
at org.springframework.integration.dispatcher.Default MessageDispatcher.d
oDispatch(DefaultMessageDispatcher.java:183)
at org.springframework.integration.dispatcher.Default MessageDispatcher.a
ccess$2(DefaultMessageDispatcher.java:176)
at org.springframework.integration.dispatcher.Default MessageDispatcher$D
ispatcherTask.run(DefaultMessageDispatcher.java:21 7)
at org.springframework.integration.scheduling.SimpleM essagingTaskSchedul
er$MessagingTaskRunner.run(SimpleMessagingTaskSche duler.java:136)
at java.util.concurrent.Executors$RunnableAdapter.cal l(Executors.java:41
7)
at java.util.concurrent.FutureTask$Sync.innerRunAndRe set(FutureTask.java
:280)
at java.util.concurrent.FutureTask.runAndReset(Future Task.java:135)
at java.util.concurrent.ScheduledThreadPoolExecutor$S cheduledFutureTask.
access$101(ScheduledThreadPoolExecutor.java:65)
at java.util.concurrent.ScheduledThreadPoolExecutor$S cheduledFutureTask.
runPeriodic(ScheduledThreadPoolExecutor.java:142)
at java.util.concurrent.ScheduledThreadPoolExecutor$S cheduledFutureTask.
run(ScheduledThreadPoolExecutor.java:166)
at java.util.concurrent.ThreadPoolExecutor$Worker.run Task(ThreadPoolExec
utor.java:650)
at java.util.concurrent.ThreadPoolExecutor$Worker.run (ThreadPoolExecutor
.java:675)
at java.lang.Thread.run(Thread.java:595)

How do I change (configure) the rejection limit?

[Mark Fisher]

The rejection limit for a channel's dispatcher can be configured with a sub-element of the channel's element:


<channel id="errorChannel">
<dispatcher-policy rejection-limit="1"/>
</channel>


-Mark