activemq-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Martin Lichtin <lich...@yahoo.com.INVALID>
Subject Re: What happens with JMSRedelivered when server moves message to DLQ
Date Thu, 12 Nov 2015 11:19:52 GMT
Trying to understand why dlqDeliveryFailureCause has a 'null' value, it seems that in ActiveMQMessageConsumer.dispatch()
the code 

                            } catch (RuntimeException e) {
                                LOG.error(getConsumerId() +
" Exception while processing message: " + md.getMessage().getMessageId(), e);
                                if (isAutoAcknowledgeBatch()
|| isAutoAcknowledgeEach() || session.isIndividualAcknowledge()) {
                                    // schedual redelivery
and possible dlq processing
                                    md.setRollbackCause(e);
                                    rollback();
                                } else {
                                    // Transacted or Client
ack: Deliver the
                                    // next message.
                                    afterMessageIsConsumed(md,
false);
                                }
                            }
should also set md.setRollbackCause(e) in the else clause?
- Martin

 
      From: Martin Lichtin <lichtin@yahoo.com>
 To: Gary Tully <gary.tully@gmail.com>; ActiveMQ Users <users@activemq.apache.org>

 Sent: Wednesday, November 4, 2015 12:32 PM
 Subject: Re: What happens with JMSRedelivered when server moves message to DLQ
   
I'm not actually talking about the counter, but the Boolean flag 'JMSRedelivered'.
Anyways, you're right that it should work when setting persistJMSRedelivered=true (I forgot
about this option).

Regarding the "poison cause", is it not possible for the client side to return a non-null
cause?
For example, when a message ends up in DLQ, it has additional property:

dlqDeliveryFailureCause=java.lang.Throwable: Exceeded redelivery policy limit:RedeliveryPolicy
{destination = null, collisionAvoidanceFactor = 0.15, maximumRedeliveries = 0, maximumRedeliveryDelay
= -1, initialRedeliveryDelay = 1000, useCollisionAvoidance = false, useExponentialBackOff
= false, backOffMultiplier = 5.0, redeliveryDelay = 1000}, cause:null, 


This is nice, but pretty useless information.
A real value would be if "cause:null" would instead be shwoing the Exception that the application
threw.

- Martin

>________________________________
> From: Gary Tully <gary.tully@gmail.com>
> To: Martin Lichtin <lichtin@yahoo.com>; ActiveMQ Users <users@activemq.apache.org>

> Sent: Wednesday, November 4, 2015 11:52 AM
> Subject: Re: What happens with JMSRedelivered when server moves message to DLQ
> 
>
> that is intended. the dlq enqueue is a new message. the poison cause property will have
some good information but it would make sense to add a property that captures the value of
that counter. the only issue is that the value is typically interpreted client side and remains
1 on the broker so it may be of limited value. if you want to depend on the redelivery counter
you may want to peek at the persistjmsredelivery option.
>
>
> On Tue 3 Nov 2015 3:45 PM Martin Lichtin <lichtin@yahoo.com.invalid> wrote:
>
> I see the JMSRedelivered flag goes back to 'false' when # of redeliveries is exceeded
> and ActiveMQ server moving the message into the DLQ.
> 
> Is this done on purpose? I'd rather expect the flag stay 'true', as this state should
be preserved.
> 
> - Martin


   

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message