Thanks a lot Claus.
--
View this message in context:
http://camel.465427.n5.nabble.com/Camel-2-9-1-DeadLetterChannel-infinite-loop-tp5714961p5715765.html
Sent from the Camel - Users mailing list archive at Nabble.com.
On Mon, Jul 9, 2012 at 4:49 PM, E.Gherardini wrote:
> Hello Claus,
> I am getting problems in running this inside an OSGi context.
>
> In my opinion this should work registering the bean as a Service in the OSGi
> context, from the same bundle which adds the route to the CamelContext, but
> in suc
Hello Claus,
I am getting problems in running this inside an OSGi context.
In my opinion this should work registering the bean as a Service in the OSGi
context, from the same bundle which adds the route to the CamelContext, but
in such way when the BeanProcessor gets the message it cannot load the
Hello sarfarj,
this is the doTry() doCatch() solution I've found. I remark that the
approach suggested by Claus (which is basically using the Recipient List EIP
to choose the dead letter queue at runtime) is much more cleaner.
@Override
public void configure() throws Exception {
> Consider sending the message to the persistent DLC
With something like deadLetterChannel("jms:persistentQueue") of course :) .
--
Henryk Konsek
http://henryk-konsek.blogspot.com
> What I am trying to achieve is a redelivery happening from the beginning of
> the route, putting the message back on the inbound queue (which lives in a
> distributed message broker) so to reduce at minimum the possibility of
> loosing the message in case the JVM performing the camel retries fail
Could you please paste the code here? what you did to resolved?
--
View this message in context:
http://camel.465427.n5.nabble.com/Camel-2-9-1-DeadLetterChannel-infinite-loop-tp5714961p5715399.html
Sent from the Camel - Users mailing list archive at Nabble.com.
Thanks a lot Claus,
I was able to achieve the same result with the doTry() doCatch() approach,
but your solution is much cleaner since it leverages already existing Camel.
Thanks a lot again.
--
View this message in context:
http://camel.465427.n5.nabble.com/Camel-2-9-1-DeadLetterChannel-infinit
On Sun, Jun 24, 2012 at 1:53 PM, E.Gherardini wrote:
> Hello Claus,
> thanks for answering.
> unfortunately clients of these routes can't be transactional, they can only
> be fire-and-forget, that is why I am implementing this logic.
>
> Could a doTry / doCatch route be a reasonable approach in yo
Hello Claus,
thanks for answering.
unfortunately clients of these routes can't be transactional, they can only
be fire-and-forget, that is why I am implementing this logic.
Could a doTry / doCatch route be a reasonable approach in your opinion ?
--
View this message in context:
http://camel.4654
On Sun, Jun 24, 2012 at 11:38 AM, E.Gherardini wrote:
> Hello Filippo,
> thanks again for replying me.
>
> You caught exactly my point: I do not want to loose messages: unfortunately
> my application cannot use transactions, that's why I am handling this by
> hand.
>
> I am starting to think that
Hello Filippo,
thanks again for replying me.
You caught exactly my point: I do not want to loose messages: unfortunately
my application cannot use transactions, that's why I am handling this by
hand.
I am starting to think that the only possible way is writing my own error
handler using standard
According with dead letter channel definition if you can't deliver
message, it may be elect to move the message to a dead letter channel.
With camel you can use different redelivery policy to do it .
>From your message seems to understand that you don't want loose
message when something bad happe
Or, to better say, I would like to instruct the Camel
DeadletterChannelErrorHandler to resent the message to the inbound queue
when redelivering, and to the dead letter queue when all redeliveries
failed.
is this possible ?
--
View this message in context:
http://camel.465427.n5.nabble.com/Camel
Hello Filippo,
thanks for replying.
What I am trying to achieve is a redelivery happening from the beginning of
the route, putting the message back on the inbound queue (which lives in a
distributed message broker) so to reduce at minimum the possibility of
loosing the message in case the JVM perf
Hello,
It's correct.
>From my point of view to break infinite loop you need configure your
RedeliveryPolicy without
.to(Constants.INBOUND_QUEUE) instruction
--Filippo
2012/6/23 E.Gherardini :
> My question lies behind the fact that I understood onException clause is used
> until the set maximu
My question lies behind the fact that I understood onException clause is used
until the set maximumRedelivery is reached, and then the DLC would come in.
Is this correct?
--
View this message in context:
http://camel.465427.n5.nabble.com/Camel-2-9-1-DeadLetterChannel-infinite-loop-tp5714961p571
Ah i forgot to mention that the above route is preceeded by another route,
with its own errorHandler:
[code]
dlcb = new
DeadLetterChannelBuilder(Constants.MAIN_INBONUND_QUEUE+"/deadLetter");
dlcb.setFailureProcessor(new MyLoggingProcessor("Message
Delivery
Failure"));
...
@Override
18 matches
Mail list logo
