Aaron Whiteside created CAMEL-7939:
--------------------------------------
Summary: Pluggable RedeliveryStrategy for RedeliveryErrorHandler
Key: CAMEL-7939
URL: https://issues.apache.org/jira/browse/CAMEL-7939
Project: Camel
Issue Type: Improvement
Components: camel-core
Affects Versions: 2.14.0
Reporter: Aaron Whiteside
Priority: Critical
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 to schedule messages for redelivery and
send() them back using 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..
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).
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)
