camel-issues mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Aaron Whiteside (JIRA)" <j...@apache.org>
Subject [jira] [Updated] (CAMEL-7939) Pluggable RedeliveryStrategy for RedeliveryErrorHandler
Date Tue, 21 Oct 2014 22:29:34 GMT

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

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 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..  and not to mention we have
ended up duplicating a large portion of the RedeliveryErrorHandler 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).

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

Mime
View raw message