[
https://issues.apache.org/jira/browse/CAMEL-7939?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Claus Ibsen updated CAMEL-7939:
-------------------------------
Estimated Complexity: Advanced (was: Moderate)
> Pluggable RedeliveryStrategy for RedeliveryErrorHandler
> -------------------------------------------------------
>
> Key: CAMEL-7939
> URL: https://issues.apache.org/jira/browse/CAMEL-7939
> Project: Camel
> Issue Type: New Feature
> Components: camel-core
> Affects Versions: 2.14.0
> Reporter: Aaron Whiteside
>
> Pluggable RedeliveryStrategy for RedeliveryErrorHandler
> The logic of calling executorService.schedule() and RedeliveryPolicy.sleep()
> in RedeliveryErrorHandler.process() and executorService.schedule()/submit()
> in RedeliveryErrorHandler.processAsyncErrorHandler() should be abstracted
> into a RedeliveryStrategy.
> The use case for this is to allow custom scheduled retries using JMS. Most if
> not all JMS implementations provide a vendor specific way to schedule a
> message for delivery at a specified time in the future. Currently we are
> using a custom Processor in onException() blocks (with disableRedelivery=true
> and handled=true) to manually schedule messages for redelivery using
> ProducerTemplate.send() and exchange.getFromEndpoint(). However this does not
> play well with Camel's built in Exchange Properties that deal with retry
> count, retry delay, etc and we have ended up duplicating camel's build in
> properties using our own custom properties. So that the various interceptors
> don't strip them.. and not to mention we have ended up duplicating a large
> portion of the RedeliveryErrorHandler's logic in our own Processor.
> We do not use camel's built in synchronous retry because it blocks the
> calling thread and we do no use the async scheduled retry because it is not
> safe, Exchange's are not persisted and when the context is shutdown they will
> be lost (camel's DefaultShutdownStrategy with a timeout does not help, it's
> not always possible to get an exchange accepted by an endpoint before
> shutting down - Think HTTP notifications to clients...)
> And we do not use our JMS vendors automatic retry mechanism, because it means
> we lose control of the retries on a per route basis (all retry options must
> be configured and administered on the broker side). And there is no metadata
> in the Exchange about the retry count, message history, etc.. as the original
> message is redelivered (transaction rollback/unacked etc).
> If the actual logic of sending and scheduling retries was abstracted we could
> plug in our own strategy to do this based on our JMS vendor (HornetQ). I
> imagine that our implementation would be almost identical for ActiveMQ too
> (different JMS header). And we would be willing to submit it back to the
> Camel Project.
> We would also be willing to submit a patch to pull out logic into a
> RedeliveryStrategy, just need a little guidance.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
