Fwd: Active MQ DLQ messages with a dlqDeliveryFailureCause cause that is null

classic Classic list List threaded Threaded
4 messages Options
Reply | Threaded
Open this post in threaded view
|

Fwd: Active MQ DLQ messages with a dlqDeliveryFailureCause cause that is null

nomit babraa
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 [hidden email] 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
-------
Reply | Threaded
Open this post in threaded view
|

Re: Active MQ DLQ messages with a dlqDeliveryFailureCause cause that is null

Claus Ibsen-2
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 <[hidden email]> 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 [hidden email] 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
Reply | Threaded
Open this post in threaded view
|

Re: Active MQ DLQ messages with a dlqDeliveryFailureCause cause that is null

nomit babraa
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 <[hidden email]> 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 <[hidden email]> 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 [hidden email] 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
Reply | Threaded
Open this post in threaded view
|

Re: Active MQ DLQ messages with a dlqDeliveryFailureCause cause that is null

Claus Ibsen-2
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 <[hidden email]> 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 <[hidden email]> 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 <[hidden email]> 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 [hidden email] 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