[
https://issues.apache.org/jira/browse/CAMEL-7939?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Aaron Whiteside updated CAMEL-7939:
-----------------------------------
Description:
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.
was:
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, 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.
> 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 (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)
