Announcement Announcement Module
No announcement yet.
Best practice regarding retries and many channels Page Title Module
Move Remove Collapse
Conversation Detail Module
  • Filter
  • Time
  • Show
Clear All
new posts

  • Best practice regarding retries and many channels


    I have an application that dynamically creates channels (DirectChannel) in a BeanFactoryPostProcessor in a manner similar to how the IntegrationNamespaceHandler works. Many channels may send messages to a single MessageHandler. My question is how best to handle failures within the MessageHandler with regard to requeuing messages for retry.

    The desirable behavior is that a message that fails is requeued to the channel it originally came from after a delay, but only a limited number of times. The real problem is that the handler doesn't know from which channel the message was received making the requeuing awkward.

    I've considered doing something like using a ChannelIntercepter to push the original channel into the message headers, but it seems hackish. I'm sure there's a better way of doing this.

    Also, do folks have an opinion on whether it's best to have the MessageHandler throw an exception and handle requeuing via the error channel(s) or to requeue "manually" with a MessageChannelTemplate within the handler itself. The former seems like a better separation of concerns and decouples the error handling behavior but at the cost of potentially complicating the code greatly (i.e. figuring out which channel to queue to, separating permanent failures from temporary failures on the error channel). Another option would be to create a channel called retryChannel and manually queue to it, have it do the delay, and then let it requeue to the proper original channel which gives the benefit of avoiding confusion on the errorChannel between perm / temp errors and still pushing the exact requeuing semantics and configuration out of the handler.

    I don't know if this is very clear.