Announcement Announcement Module
Collapse
No announcement yet.
Error Channel Behavior Page Title Module
Move Remove Collapse
X
Conversation Detail Module
Collapse
  • Filter
  • Time
  • Show
Clear All
new posts

  • Error Channel Behavior

    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.

  • #2
    Similar to deploy/undeploy

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

    Thanks,
    Caroline.

    Comment


    • #3
      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

      Comment


      • #4
        Error Channel configuration

        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.ErrorListener"/>

        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.

        Comment


        • #5
          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

          Comment


          • #6
            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:
            Code:
            <endpoint input-channel="errorChannel"
                          default-output-channel="outputChannel"
                          handler-ref="errorListener"
                          handler-method="handle"
                          error-handler="loggingOnlyErrorHandler/>
            Thanks,
            Mark

            Comment


            • #7
              Test Case

              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)

              Comment


              • #8
                Test Case

                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?

                Comment


                • #9
                  The rejection limit for a channel's dispatcher can be configured with a sub-element of the channel's element:
                  Code:
                  <channel id="errorChannel">
                      <dispatcher-policy rejection-limit="1"/>
                  </channel>
                  -Mark

                  Comment

                  Working...
                  X