Redeliver to end of Endpoint/Queue?

[efender <er...@fender.net>]

Is it possible to have an exchange/message that threw an exception during
processing be redelivered to the end of the queue instead of staying at the
front of the queue and holding up all messages that are behind it?  Some
sort of interceptor or callback or customization to DeadLetterChannel?  I'm
sure there are ways to do this, but what might be considered best practice?

Thanks.

Eric
-- 
View this message in context: http://www.nabble.com/Redeliver-to-end-of-Endpoint-Queue--tp22060777s22882p22060777.html
Sent from the Camel - Users mailing list archive at Nabble.com.

Re: Redeliver to end of Endpoint/Queue?

[Claus Ibsen <cl...@gmail.com>]

Hi


On Wed, Feb 18, 2009 at 4:21 AM, efender <er...@fender.net> wrote:
>
> After thinking about this some more, what I'd really like is to be able to
> consume a message at some time in the future.  If an exception occurs during
> processing, instead of the processing thread sleeping for the delay period,
> the message should be re-delivered with something like a consume_time
> header.  Then the message consumer will change its selector every time it
> polls, something like "consume_time > System.currentTimeInMillis()"
> Thoughts anyone?
Interesting idea. I am thinking that we could re use the Quartz
component or eg the timer.

Then you could send the Exchange to the quartz component with
- The Original Exchange
- The Time in the future it should be resend
- URI to where to send it to

Then you would be able to do something like

onException(Exception.class)
.handled(true)
.to("bean:prepareForFutureRedelivery")
.to("quartz://redeliverjob")

Then the bean prepareForFutureRedelivery prepares the Exchange by
- setting a special header with the future time
- setting a special header with the endpoint URI it should be sent to
when activated

We could of course prepare such a bean/processor out of the box in
Camel and have a nice DSL for it.
But before hand we need to get the pieces together, we can always
polish it later.

Maybe we can use the timer instead of quartz or some other new component

Any thoughts?




> --
> View this message in context: http://www.nabble.com/Redeliver-to-end-of-Endpoint-Queue--tp22060777s22882p22071417.html
> Sent from the Camel - Users mailing list archive at Nabble.com.
>
>



-- 
Claus Ibsen
Apache Camel Committer

Open Source Integration: http://fusesource.com
Blog: http://davsclaus.blogspot.com/

Re: Redeliver to end of Endpoint/Queue?

[efender <er...@fender.net>]

After thinking about this some more, what I'd really like is to be able to
consume a message at some time in the future.  If an exception occurs during
processing, instead of the processing thread sleeping for the delay period,
the message should be re-delivered with something like a consume_time
header.  Then the message consumer will change its selector every time it
polls, something like "consume_time > System.currentTimeInMillis()"
Thoughts anyone?
-- 
View this message in context: http://www.nabble.com/Redeliver-to-end-of-Endpoint-Queue--tp22060777s22882p22071417.html
Sent from the Camel - Users mailing list archive at Nabble.com.