Announcement Announcement Module
No announcement yet.
Poller with Advice-Chain Page Title Module
Move Remove Collapse
Conversation Detail Module
  • Filter
  • Time
  • Show
Clear All
new posts

  • Poller with Advice-Chain


    I'm trying to use a default poller with an advice chain to add a retry advice to every polling consumer.

    To my suprise the retry advice is not working.

    When used in a pollers advice chain like

            <poller id="default-poller" 
                    <ref bean="txAdvice"/> 
                    <ref bean="retryAdvice"/>
    the retry advice never executes.

    In contrast when using the same retry advice in a <request-handler-advice-chain> like this:

                    <beans:ref bean="retryAdvice"/>
    everything is fine. So to me it looks like one can't combine a retry advice in a advice in a poller.

    As the docu states:
    Prior to Spring Integration 2.2, you could add behavior to an entire Integration flow by adding an AOP Advice to a poller's <advice-chain /> element.
    Does this mean in SI 2.2 and up this isnt possible any more? One must a behavior to each handler separately even if its always the same?

    When debuggin into the framework code there is an if decision in class AbstractRequestHandlerAdvice which states:
    if (!isMessageMethod) {
       return invocation.proceed();
    } else {
       Message<?> message = (Message<?>) arguments[0];
       try {
    	return doInvoke(new ExecutionCallback() {
       } ....
    For Advices in a poller advice chain the 'isMessageMethod' condition is always false, so the doInvoke method of the concrete subclass like RequestHandlerRetryAdvice is never called.

    Is this intentional?

    Regards Steve

  • #2
    The RequestHandlerRetryAdvice is for advising request handlers only; it is not intended for use with a poller (and won't work, as you have discovered).

    We currently don't provide an advice for retry with pollers; one issue is that at the point where the advice is applied to the poller, we don't yet have access to the message (because we haven't polled yet). So, there's no context available for functionality like retry etc. So, certainly stateful retry won't be possible, but I suppose a simple stateless retry would be possible in this case. However, since you don't have access to the message, it's hard to figure out what you could do when the retries are exhausted.

    Advices applied to whole flows using an advised poller are limited to generic functionality such as transactions etc.

    Even though the RequestHandlerRetryAdvice won't work, you can implement your own advice (... implements MethodInterceptor) using a RetryTemplate with stateless retry. But again, it would have limited use, particularly when the retries are exhausted.

    If you come up with something that you think will be generally useful to others, feel free to contribute it...


    • #3
      Also, see this thread

      ...where the poster wanted to advise a chunk of downstream flow instead of just a request handler. As I said in that thread, you can use a RequestHandlerAdvice to advise the entire downstream flow but it's a little involved...
      Last edited by Gary Russell; May 6th, 2013, 08:49 AM.


      • #4
        Sorry; wrong link.


        • #5
          Hi Gary,

          thanks for the reply. So I have to rearrange the advice and put it into the concrete service-activators.

          I think it would be helpful to log or warn the user if the advice is omitted. Simply invoking invocation.proceed without any notice and no error message when constructing the context lead to some confusion why the advice is not working.


          • #6
            I agree; please go ahead and open a JIRA issue; we shoud emit a warning.