On Fri, Jun 8, 2012 at 10:05 AM, gramanero wrote:
> How do you get the message to "bounce off the front of the queue"? Can you
> control whether the message is on the front or back of the queue? You
> brought up an interesting point at the beginning of this thread that
> indicated that a message c
his pans out for you.
--
View this message in context:
http://camel.465427.n5.nabble.com/Transacted-vs-DeadLetterQueue-tp5713992p5714205.html
Sent from the Camel - Users mailing list archive at Nabble.com.
On Fri, Jun 8, 2012 at 8:07 AM, gramanero wrote:
>
> If I let the transaction rollback, then I have the message on the queue
> still and then run the risk of trying to process it a second time which
> will result in the same scenario and most likely end up in an endless loop.
> Unless I configure
amel that the exception has been
> > > > "handled" (via
> > > > >> > the handled clause) and I route the message to the dead letter
> > > queue,
> > > > thus
> > > > >> > moving the "bad message&quo
l.465427.n5.nabble.com/Transacted-vs-DeadLetterQueue-tp5713992p5714190.html
> Sent from the Camel - Users mailing list archive at Nabble.com.
>
the DLQ.
>
> Like I said, maybe I'm just missing something here.
>
> --
> View this message in context:
> http://camel.465427.n5.nabble.com/Transacted-vs-DeadLetterQueue-tp5713992p5714188.html
> Sent from the Camel - Users mailing list archive at Nabble.com.
>
Blueprint? Hmmm...I have not heard or seen that yet. lol...great. Another
rabbit hole for me to dive down into. ;-)
--
View this message in context:
http://camel.465427.n5.nabble.com/Transacted-vs-DeadLetterQueue-tp5713992p5714190.html
Sent from the Camel - Users mailing list archive at
; the
> Apache stack and all the Camel has to offer (+ServiceMi, ActiveMQ, etc).
>
> --
> View this message in context:
> http://camel.465427.n5.nabble.com/Transacted-vs-DeadLetterQueue-tp5713992p5714186.html
> Sent from the Camel - Users mailing list archive at Nabble.com.
>
here.
--
View this message in context:
http://camel.465427.n5.nabble.com/Transacted-vs-DeadLetterQueue-tp5713992p5714188.html
Sent from the Camel - Users mailing list archive at Nabble.com.
n love with the
Apache stack and all the Camel has to offer (+ServiceMi, ActiveMQ, etc).
--
View this message in context:
http://camel.465427.n5.nabble.com/Transacted-vs-DeadLetterQueue-tp5713992p5714186.html
Sent from the Camel - Users mailing list archive at Nabble.com.
ad letter
> > queue,
> > > thus
> > > >> > moving the "bad message" out of the way of the messages remaining
> > on
> > > the
> > > >> > queue. I think the key here is the use of the "handled" clause
> that
> > > tells
remaining
> on
> > the
> > >> > queue. I think the key here is the use of the "handled" clause that
> > tells
> > >> > Camel that the message has been handled and therefore to NOT
> rollback
> > the
> > >> > transaction. The altern
k
> the
> >> > transaction. The alternative choice is to tell Camel to "continue" on
> with
> >> > its normal processing which would have rolled back the transaction
> and put
> >> > the message back onto the queue (via the "continue&qu
Camel to "continue" on with
>> > its normal processing which would have rolled back the transaction and put
>> > the message back onto the queue (via the "continue" clause...at least I
>> > think it is a clause).
>> >
>> > Hope that helps.
>> >
&
ollback the
> > transaction. The alternative choice is to tell Camel to "continue" on with
> > its normal processing which would have rolled back the transaction and put
> > the message back onto the queue (via the "continue" clause...at least I
> > think it
he
>>> transaction. The alternative choice is to tell Camel to "continue" on with
>>> its normal processing which would have rolled back the transaction and put
>>> the message back onto the queue (via the "continue" clause...at least I
>>> think it is a clause).
>>>
>>> Hope that helps.
>>>
>>> --
>>> View this message in context:
>>> http://camel.465427.n5.nabble.com/Transacted-vs-DeadLetterQueue-tp5713992p5714139.html
>>> Sent from the Camel - Users mailing list archive at Nabble.com.
th
>> its normal processing which would have rolled back the transaction and put
>> the message back onto the queue (via the "continue" clause...at least I
>> think it is a clause).
>>
>> Hope that helps.
>>
>> --
>> View this message in context:
>> http://camel.465427.n5.nabble.com/Transacted-vs-DeadLetterQueue-tp5713992p5714139.html
>> Sent from the Camel - Users mailing list archive at Nabble.com.
nue" on with
> its normal processing which would have rolled back the transaction and put
> the message back onto the queue (via the "continue" clause...at least I
> think it is a clause).
>
> Hope that helps.
>
> --
> View this message in context:
> http:/
hat helps.
--
View this message in context:
http://camel.465427.n5.nabble.com/Transacted-vs-DeadLetterQueue-tp5713992p5714139.html
Sent from the Camel - Users mailing list archive at Nabble.com.
hat there would be a
> simple translation, but it does make it more difficult to determine which
> exceptions I want to look for a then route to the DLQ.
>
> Not sure if that helps you, but it seems to be a possible approach for me.
>
> --
> View this message in context:
&g
I'm not sure that there would be a
simple translation, but it does make it more difficult to determine which
exceptions I want to look for a then route to the DLQ.
Not sure if that helps you, but it seems to be a possible approach for me.
--
View this message in context:
http://camel.465427.n5.
On Wed, Jun 6, 2012 at 11:35 PM, Claus Ibsen wrote:
>
> Nothing is reliable.
>
> You would need to use for example Camel's dead letter channel, and
> send the messages to another JMS queue, which is the DLQ.
> And then use transactions so it appears as a atomic operation.
With transactions and D
quent messages in the queue. Right?
>> >
>>
>> Yes, but a broker usually have a way to configure a upper cap, and
>> move the poisonous message to a DLQ.
>> This is broker specific and you need to read up on what your broker
>> support.
>>
>>
&
ueue. Right?
> >
>
> Yes, but a broker usually have a way to configure a upper cap, and
> move the poisonous message to a DLQ.
> This is broker specific and you need to read up on what your broker
> support.
>
>
> > --
> > View this message in context:
> http://
> http://camel.465427.n5.nabble.com/Transacted-vs-DeadLetterQueue-tp5713992p5714078.html
> Sent from the Camel - Users mailing list archive at Nabble.com.
--
Claus Ibsen
-
FuseSource
Email: cib...@fusesource.com
Web: http://fusesource.com
Twitter: davsclaus, fusenews
Blog: http
this message in context:
http://camel.465427.n5.nabble.com/Transacted-vs-DeadLetterQueue-tp5713992p5714078.html
Sent from the Camel - Users mailing list archive at Nabble.com.
Thanks Claus.
So is collision avoidance a different mechanism than the exponential
back-off settings or do they work together?
--
View this message in context:
http://camel.465427.n5.nabble.com/Transacted-vs-DeadLetterQueue-tp5713992p5714060.html
Sent from the Camel - Users mailing list
ision
avoidance on the ethernet).
> Thanks.
>
>
>
>
> --
> View this message in context:
> http://camel.465427.n5.nabble.com/Transacted-vs-DeadLetterQueue-tp5713992p5714032.html
> Sent from the Camel - Users mailing list archive at Nabble.com.
--
Claus Ibsen
---
The only
explanation that I can find is:
"Should the redelivery policy use collision avoidance"
This really isn't telling me a whole lot. I can't seem to find anything in
either book that discusses it either.
Thanks.
--
View this message in context:
http://
e
> messages are constantly trying to be routed to the unavailable cxfrs
> endpoint thus sort of thrashing the system.
>
> I'm just looking for some opinions to how this type of problem is typically
> solved or some sort of best practice to this use case.
>
> Thanks!
>
x27;m just looking for some opinions to how this type of problem is typically
solved or some sort of best practice to this use case.
Thanks!
--
View this message in context:
http://camel.465427.n5.nabble.com/Transacted-vs-DeadLetterQueue-tp5713992.html
Sent from the Camel - Users mailing list archive at Nabble.com.
31 matches
Mail list logo
