Announcement Announcement Module
No announcement yet.
Stateful retry with backoff wasting threads Page Title Module
Move Remove Collapse
Conversation Detail Module
  • Filter
  • Time
  • Show
Clear All
new posts

  • Stateful retry with backoff wasting threads

    When using stateful retry, the exception is rethrown after each attempt.

    With a backoff policy like ExponentialBackOffPolicy the current thread is blocked in a sleep / object even if the
    context is not hold by the thread. So threads are blocked in sleep doing nothing not even holding context for the
    next retry.

    These threads are simply waiting to rethrow the catched exception.

    Is there a better possibilty that is not wasting threads? Perhaps in conjuction with a priority channel?

    Regards steve

  • #2
    Or how about an additional delayer? so retry would not simply rethrow the exception causing a rollback
    and put the message back into the queue channel, but reroute it to a delayer.


    • #3
      I understand your concern; we do point this out as a caution in the Reference Documentation.

      In typical situations, stateful retry is used when the message source is some kind of message-driven transactional resource (e.g. JMS or AMQP), where the exceptoin is thrown back to the container and it re-submits the message.

      There's not really a good solution. Yes, it could be routed to a delayer, but the delayer would have to be backed by a persistent message store (such as JDBC); that then introduces a lot more complexity - either XA transactions, or duplicate message detection.

      Many JMS brokers (e.g. ActiveMQ) provide a backoff policy at the broker level (e.g. ActiveMQ's redelivery policy). So, we would generally recommend doing the backoff there, if possible, rather than within the advice.

      I assume this is related to your other post where you want to use the retry advice from a poller (which was not its original intent).

      The retry advice does support a pluggable MessageRecoverer and we provide a ErrorMessageSendingRecoverer. So, you could use a short retry policy with no backoff and send the message to a delayer using that recoverer.

      Hope that helps.