You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@activemq.apache.org by nomit babraa <h....@sheffield.ac.uk> on 2020/04/26 08:23:02 UTC
Active MQ DLQ messages with a dlqDeliveryFailureCause cause that is null
Hi
I'm using the Camel Transactional Client EIP with *all* delivery
configured in AMQ.
When I use a transacted JMS client, camel propagates non handled
exceptions back to the Broker. After max redeliveries the message is
sent to the AMQ configured DLQ, as expected.
I've noticed that my DLQ messages have a dlqDeliveryFailureCause header.
And this header has a "cause" item which is null for me:
"java.lang.Throwable: Exceeded redelivery policy limit:RedeliveryPolicy
{destination = null, collisionAvoidanceFactor = 0.15,
maximumRedeliveries = 3, maximumRedeliveryDelay = -1,
initialRedeliveryDelay = 2000, useCollisionAvoidance = false,
useExponentialBackOff = true, backOffMultiplier = 2.0, redeliveryDelay
= 1000}, cause:null"
I was wondering:
1) Should this "cause" be null? Is this an error in my setup?
2) What mechanism sets the cause to not null?
3) Ultimately, am I missing something here where an exception in my
camel route can or should be written to this "cause" value?
Thanks for any advice
n
Re: Active MQ DLQ messages with a dlqDeliveryFailureCause cause that
is null
Posted by nomit babraa <h....@sheffield.ac.uk>.
Cheers - that would be very kind.
Not sure if I should also post in the camel users list?
On Mon, 27 Apr 2020 at 16:03, Jean-Baptiste Onofre <jb...@nanthrax.net> wrote:
>
> Hi,
>
> I will take a look on the first thread email tomorrow morning.
>
> Sorry for the delay.
>
> Regards
> JB
>
> > Le 27 avr. 2020 à 17:00, nomit babraa <h....@sheffield.ac.uk> a écrit :
> >
> > Hi
> >
> > Wondering if anyone can help with this please?
> >
> > We are on AMQ version 5.15.0 and I found this
> > https://issues.apache.org/jira/browse/AMQ-6042, so I'm assuming that
> > is not an issue for us?
> > https://github.com/apache/activemq/blob/activemq-5.15.x/activemq-client/src/main/java/org/apache/activemq/ActiveMQMessageConsumer.java#L1409
> > looks to have the fix.
> >
> > However this may not be relevant here, as I'm using a Camel to consume
> > the message?
> > There seems to both a JMS and ActiveMQ Component listed at
> > https://camel.apache.org/components/latest/index.html
> >
> > To be fair I'm nor sure which I'm using. Does only one populate this cause?
> >
> > Cheers
> >
> > n
> >
> > On Sun, 26 Apr 2020 at 09:23, nomit babraa <h....@sheffield.ac.uk> wrote:
> >>
> >> Hi
> >>
> >> I'm using the Camel Transactional Client EIP with *all* delivery
> >> configured in AMQ.
> >>
> >> When I use a transacted JMS client, camel propagates non handled
> >> exceptions back to the Broker. After max redeliveries the message is
> >> sent to the AMQ configured DLQ, as expected.
> >>
> >> I've noticed that my DLQ messages have a dlqDeliveryFailureCause header.
> >>
> >> And this header has a "cause" item which is null for me:
> >>
> >> "java.lang.Throwable: Exceeded redelivery policy limit:RedeliveryPolicy
> >> {destination = null, collisionAvoidanceFactor = 0.15,
> >> maximumRedeliveries = 3, maximumRedeliveryDelay = -1,
> >> initialRedeliveryDelay = 2000, useCollisionAvoidance = false,
> >> useExponentialBackOff = true, backOffMultiplier = 2.0, redeliveryDelay
> >> = 1000}, cause:null"
> >>
> >> I was wondering:
> >>
> >> 1) Should this "cause" be null? Is this an error in my setup?
> >> 2) What mechanism sets the cause to not null?
> >> 3) Ultimately, am I missing something here where an exception in my
> >> camel route can or should be written to this "cause" value?
> >>
> >> Thanks for any advice
> >>
> >> n
>
Re: Active MQ DLQ messages with a dlqDeliveryFailureCause cause that
is null
Posted by Jean-Baptiste Onofre <jb...@nanthrax.net>.
Hi,
I will take a look on the first thread email tomorrow morning.
Sorry for the delay.
Regards
JB
> Le 27 avr. 2020 à 17:00, nomit babraa <h....@sheffield.ac.uk> a écrit :
>
> Hi
>
> Wondering if anyone can help with this please?
>
> We are on AMQ version 5.15.0 and I found this
> https://issues.apache.org/jira/browse/AMQ-6042, so I'm assuming that
> is not an issue for us?
> https://github.com/apache/activemq/blob/activemq-5.15.x/activemq-client/src/main/java/org/apache/activemq/ActiveMQMessageConsumer.java#L1409
> looks to have the fix.
>
> However this may not be relevant here, as I'm using a Camel to consume
> the message?
> There seems to both a JMS and ActiveMQ Component listed at
> https://camel.apache.org/components/latest/index.html
>
> To be fair I'm nor sure which I'm using. Does only one populate this cause?
>
> Cheers
>
> n
>
> On Sun, 26 Apr 2020 at 09:23, nomit babraa <h....@sheffield.ac.uk> wrote:
>>
>> Hi
>>
>> I'm using the Camel Transactional Client EIP with *all* delivery
>> configured in AMQ.
>>
>> When I use a transacted JMS client, camel propagates non handled
>> exceptions back to the Broker. After max redeliveries the message is
>> sent to the AMQ configured DLQ, as expected.
>>
>> I've noticed that my DLQ messages have a dlqDeliveryFailureCause header.
>>
>> And this header has a "cause" item which is null for me:
>>
>> "java.lang.Throwable: Exceeded redelivery policy limit:RedeliveryPolicy
>> {destination = null, collisionAvoidanceFactor = 0.15,
>> maximumRedeliveries = 3, maximumRedeliveryDelay = -1,
>> initialRedeliveryDelay = 2000, useCollisionAvoidance = false,
>> useExponentialBackOff = true, backOffMultiplier = 2.0, redeliveryDelay
>> = 1000}, cause:null"
>>
>> I was wondering:
>>
>> 1) Should this "cause" be null? Is this an error in my setup?
>> 2) What mechanism sets the cause to not null?
>> 3) Ultimately, am I missing something here where an exception in my
>> camel route can or should be written to this "cause" value?
>>
>> Thanks for any advice
>>
>> n
Re: Active MQ DLQ messages with a dlqDeliveryFailureCause cause that
is null
Posted by nomit babraa <h....@sheffield.ac.uk>.
Hi
Wondering if anyone can help with this please?
We are on AMQ version 5.15.0 and I found this
https://issues.apache.org/jira/browse/AMQ-6042, so I'm assuming that
is not an issue for us?
https://github.com/apache/activemq/blob/activemq-5.15.x/activemq-client/src/main/java/org/apache/activemq/ActiveMQMessageConsumer.java#L1409
looks to have the fix.
However this may not be relevant here, as I'm using a Camel to consume
the message?
There seems to both a JMS and ActiveMQ Component listed at
https://camel.apache.org/components/latest/index.html
To be fair I'm nor sure which I'm using. Does only one populate this cause?
Cheers
n
On Sun, 26 Apr 2020 at 09:23, nomit babraa <h....@sheffield.ac.uk> wrote:
>
> Hi
>
> I'm using the Camel Transactional Client EIP with *all* delivery
> configured in AMQ.
>
> When I use a transacted JMS client, camel propagates non handled
> exceptions back to the Broker. After max redeliveries the message is
> sent to the AMQ configured DLQ, as expected.
>
> I've noticed that my DLQ messages have a dlqDeliveryFailureCause header.
>
> And this header has a "cause" item which is null for me:
>
> "java.lang.Throwable: Exceeded redelivery policy limit:RedeliveryPolicy
> {destination = null, collisionAvoidanceFactor = 0.15,
> maximumRedeliveries = 3, maximumRedeliveryDelay = -1,
> initialRedeliveryDelay = 2000, useCollisionAvoidance = false,
> useExponentialBackOff = true, backOffMultiplier = 2.0, redeliveryDelay
> = 1000}, cause:null"
>
> I was wondering:
>
> 1) Should this "cause" be null? Is this an error in my setup?
> 2) What mechanism sets the cause to not null?
> 3) Ultimately, am I missing something here where an exception in my
> camel route can or should be written to this "cause" value?
>
> Thanks for any advice
>
> n
Re: Active MQ DLQ messages with a dlqDeliveryFailureCause cause that
is null
Posted by Claus Ibsen <cl...@gmail.com>.
Hi
If you have a copy of the CiA2 book, then there is a full chapter on
transactions that goes in details.
On Tue, May 5, 2020 at 6:13 PM nomit babraa <h....@sheffield.ac.uk> wrote:
>
> Hi
> Thanks for that.
>
> I've been led to believe when using the transacted client I should
> only have redelivery on AMQ.
>
> However, only now noticed that
> https://camel.apache.org/components/latest/eips/transactional-client.html
> says
>
> CONFIGURATION OF REDELIVERY : "The redelivery in transacted mode is
> not handled by Camel but by the backing system (the transaction
> manager). In such cases you should resort to the backing system how to
> configure the redelivery."
>
> and https://camel.apache.org/manual/latest/transactionerrorhandler.html says
>
> USING CAMEL TO DO REDELIVERIES: "As the TransactionErrorHandler also
> supports letting Camel do redeliveries you can use both worlds.
> Letting Camel do some redeliveries and at the end the backing
> transaction manager doing other redeliveries."
>
> This seems a little contradictory?
>
> If I use both I guess I can write my own "cause" headers to any
> message that is sent to a DLQ in the TransactionErrorHandler?
>
> I'm only using a transactional. client as that seems to be the best
> way to ensure messages are not lost if a route dies half way through
> processing a message.....
>
> Cheers
>
> n
>
>
>
> On Tue, 5 May 2020 at 14:40, Claus Ibsen <cl...@gmail.com> wrote:
> >
> > Hi
> >
> > The cause should in principle be null as its a client exception, that
> > otherwise would have to be serialized and send back over the network
> > to be stored as part of the message in the DQL. And that to my
> > knowledge doesnt happen or is possible.
> >
> > The ActiveMQ folks would be the right people to help answer.
> >
> >
> >
> > On Tue, May 5, 2020 at 2:48 PM nomit babraa <h....@sheffield.ac.uk> wrote:
> > >
> > > Hello
> > >
> > > I have an issue that relates to the interaction between AMQ and Camel
> > > and I'm not sure at which end any issue might be.
> > >
> > > I'm worried that this question might fall between the cracks... :)
> > >
> > > I've sent already to users@activemq.apache.org but have not had any
> > > response, so am now trying you guys.
> > >
> > > Cheers
> > >
> > > ------
> > > Hi
> > >
> > > I'm using the Camel Transactional Client EIP with *all* delivery
> > > configured in AMQ.
> > >
> > > When I use a transacted JMS client, camel propagates non handled
> > > exceptions back to the Broker. After max redeliveries the message is
> > > sent to the AMQ configured DLQ, as expected.
> > >
> > > I've noticed that my DLQ messages have a dlqDeliveryFailureCause header.
> > >
> > > And this header has a "cause" item which is null for me:
> > >
> > > "java.lang.Throwable: Exceeded redelivery policy limit:RedeliveryPolicy
> > > {destination = null, collisionAvoidanceFactor = 0.15,
> > > maximumRedeliveries = 3, maximumRedeliveryDelay = -1,
> > > initialRedeliveryDelay = 2000, useCollisionAvoidance = false,
> > > useExponentialBackOff = true, backOffMultiplier = 2.0, redeliveryDelay
> > > = 1000}, cause:null"
> > >
> > > I was wondering:
> > >
> > > 1) Should this "cause" be null? Is this an error in my setup?
> > > 2) What mechanism sets the cause to not null?
> > > 3) Ultimately, am I missing something here where an exception in my
> > > camel route can or should be written to this "cause" value?
> > >
> > > Thanks for any advice
> > >
> > > n
> > > -------
> >
> >
> >
> > --
> > Claus Ibsen
> > -----------------
> > http://davsclaus.com @davsclaus
> > Camel in Action 2: https://www.manning.com/ibsen2
--
Claus Ibsen
-----------------
http://davsclaus.com @davsclaus
Camel in Action 2: https://www.manning.com/ibsen2
Re: Active MQ DLQ messages with a dlqDeliveryFailureCause cause that
is null
Posted by nomit babraa <h....@sheffield.ac.uk>.
Hi
Thanks for that.
I've been led to believe when using the transacted client I should
only have redelivery on AMQ.
However, only now noticed that
https://camel.apache.org/components/latest/eips/transactional-client.html
says
CONFIGURATION OF REDELIVERY : "The redelivery in transacted mode is
not handled by Camel but by the backing system (the transaction
manager). In such cases you should resort to the backing system how to
configure the redelivery."
and https://camel.apache.org/manual/latest/transactionerrorhandler.html says
USING CAMEL TO DO REDELIVERIES: "As the TransactionErrorHandler also
supports letting Camel do redeliveries you can use both worlds.
Letting Camel do some redeliveries and at the end the backing
transaction manager doing other redeliveries."
This seems a little contradictory?
If I use both I guess I can write my own "cause" headers to any
message that is sent to a DLQ in the TransactionErrorHandler?
I'm only using a transactional. client as that seems to be the best
way to ensure messages are not lost if a route dies half way through
processing a message.....
Cheers
n
On Tue, 5 May 2020 at 14:40, Claus Ibsen <cl...@gmail.com> wrote:
>
> Hi
>
> The cause should in principle be null as its a client exception, that
> otherwise would have to be serialized and send back over the network
> to be stored as part of the message in the DQL. And that to my
> knowledge doesnt happen or is possible.
>
> The ActiveMQ folks would be the right people to help answer.
>
>
>
> On Tue, May 5, 2020 at 2:48 PM nomit babraa <h....@sheffield.ac.uk> wrote:
> >
> > Hello
> >
> > I have an issue that relates to the interaction between AMQ and Camel
> > and I'm not sure at which end any issue might be.
> >
> > I'm worried that this question might fall between the cracks... :)
> >
> > I've sent already to users@activemq.apache.org but have not had any
> > response, so am now trying you guys.
> >
> > Cheers
> >
> > ------
> > Hi
> >
> > I'm using the Camel Transactional Client EIP with *all* delivery
> > configured in AMQ.
> >
> > When I use a transacted JMS client, camel propagates non handled
> > exceptions back to the Broker. After max redeliveries the message is
> > sent to the AMQ configured DLQ, as expected.
> >
> > I've noticed that my DLQ messages have a dlqDeliveryFailureCause header.
> >
> > And this header has a "cause" item which is null for me:
> >
> > "java.lang.Throwable: Exceeded redelivery policy limit:RedeliveryPolicy
> > {destination = null, collisionAvoidanceFactor = 0.15,
> > maximumRedeliveries = 3, maximumRedeliveryDelay = -1,
> > initialRedeliveryDelay = 2000, useCollisionAvoidance = false,
> > useExponentialBackOff = true, backOffMultiplier = 2.0, redeliveryDelay
> > = 1000}, cause:null"
> >
> > I was wondering:
> >
> > 1) Should this "cause" be null? Is this an error in my setup?
> > 2) What mechanism sets the cause to not null?
> > 3) Ultimately, am I missing something here where an exception in my
> > camel route can or should be written to this "cause" value?
> >
> > Thanks for any advice
> >
> > n
> > -------
>
>
>
> --
> Claus Ibsen
> -----------------
> http://davsclaus.com @davsclaus
> Camel in Action 2: https://www.manning.com/ibsen2
Re: Active MQ DLQ messages with a dlqDeliveryFailureCause cause that
is null
Posted by Claus Ibsen <cl...@gmail.com>.
Hi
The cause should in principle be null as its a client exception, that
otherwise would have to be serialized and send back over the network
to be stored as part of the message in the DQL. And that to my
knowledge doesnt happen or is possible.
The ActiveMQ folks would be the right people to help answer.
On Tue, May 5, 2020 at 2:48 PM nomit babraa <h....@sheffield.ac.uk> wrote:
>
> Hello
>
> I have an issue that relates to the interaction between AMQ and Camel
> and I'm not sure at which end any issue might be.
>
> I'm worried that this question might fall between the cracks... :)
>
> I've sent already to users@activemq.apache.org but have not had any
> response, so am now trying you guys.
>
> Cheers
>
> ------
> Hi
>
> I'm using the Camel Transactional Client EIP with *all* delivery
> configured in AMQ.
>
> When I use a transacted JMS client, camel propagates non handled
> exceptions back to the Broker. After max redeliveries the message is
> sent to the AMQ configured DLQ, as expected.
>
> I've noticed that my DLQ messages have a dlqDeliveryFailureCause header.
>
> And this header has a "cause" item which is null for me:
>
> "java.lang.Throwable: Exceeded redelivery policy limit:RedeliveryPolicy
> {destination = null, collisionAvoidanceFactor = 0.15,
> maximumRedeliveries = 3, maximumRedeliveryDelay = -1,
> initialRedeliveryDelay = 2000, useCollisionAvoidance = false,
> useExponentialBackOff = true, backOffMultiplier = 2.0, redeliveryDelay
> = 1000}, cause:null"
>
> I was wondering:
>
> 1) Should this "cause" be null? Is this an error in my setup?
> 2) What mechanism sets the cause to not null?
> 3) Ultimately, am I missing something here where an exception in my
> camel route can or should be written to this "cause" value?
>
> Thanks for any advice
>
> n
> -------
--
Claus Ibsen
-----------------
http://davsclaus.com @davsclaus
Camel in Action 2: https://www.manning.com/ibsen2
Fwd: Active MQ DLQ messages with a dlqDeliveryFailureCause cause that
is null
Posted by nomit babraa <h....@sheffield.ac.uk>.
Hello
I have an issue that relates to the interaction between AMQ and Camel
and I'm not sure at which end any issue might be.
I'm worried that this question might fall between the cracks... :)
I've sent already to users@activemq.apache.org but have not had any
response, so am now trying you guys.
Cheers
------
Hi
I'm using the Camel Transactional Client EIP with *all* delivery
configured in AMQ.
When I use a transacted JMS client, camel propagates non handled
exceptions back to the Broker. After max redeliveries the message is
sent to the AMQ configured DLQ, as expected.
I've noticed that my DLQ messages have a dlqDeliveryFailureCause header.
And this header has a "cause" item which is null for me:
"java.lang.Throwable: Exceeded redelivery policy limit:RedeliveryPolicy
{destination = null, collisionAvoidanceFactor = 0.15,
maximumRedeliveries = 3, maximumRedeliveryDelay = -1,
initialRedeliveryDelay = 2000, useCollisionAvoidance = false,
useExponentialBackOff = true, backOffMultiplier = 2.0, redeliveryDelay
= 1000}, cause:null"
I was wondering:
1) Should this "cause" be null? Is this an error in my setup?
2) What mechanism sets the cause to not null?
3) Ultimately, am I missing something here where an exception in my
camel route can or should be written to this "cause" value?
Thanks for any advice
n
-------