camel-issues mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Claus Ibsen (JIRA)" <j...@apache.org>
Subject [jira] [Resolved] (CAMEL-7939) Pluggable RedeliveryStrategy for RedeliveryErrorHandler
Date Sun, 26 Feb 2017 08:26:44 GMT

     [ 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)

Mime
View raw message