[jira] [Resolved] (CAMEL-7939) Pluggable RedeliveryStrategy for RedeliveryErrorHandler

["Claus Ibsen (JIRA)" <ji...@apache.org>]

     [ https://issues.apache.org/jira/browse/CAMEL-7939?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Claus Ibsen resolved CAMEL-7939.
--------------------------------
    Resolution: Won't Fix

> 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.15#6346)