activemq-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Christian Tytgat (JIRA)" <>
Subject [jira] [Commented] (AMQ-1730) Bad use of Jms field JMSXDeliveryCount. Related to RedeliveryCount and message prefetch
Date Wed, 17 Dec 2014 13:50:14 GMT


Christian Tytgat commented on AMQ-1730:

Is this supposed to be fixed for topics as well as queues? (ActiveMQ 5.10.0)
The reason I ask is that we're running into this problem with a durable topic subscription.
The application uses a transacted camel route without CACHE_CONSUMER, so from what I understand,
the session gets closed after each receive and all prefetched messages (100 by default) get
redispatched by the broker. The broker however is increasing redelivery count and we see lots
of messages ending up in the DLQ.

> Bad use of Jms field JMSXDeliveryCount. Related to RedeliveryCount and message prefetch

> ----------------------------------------------------------------------------------------
>                 Key: AMQ-1730
>                 URL:
>             Project: ActiveMQ
>          Issue Type: Bug
>          Components: Broker
>    Affects Versions: 5.0.0, 5.1.0
>            Reporter: Alexis Kinsella
>            Assignee: Gary Tully
>             Fix For: 5.3.0
> JMSXDeliveryCount  has to be incremented only on transactional delivery failure ( RuntimeException
on processing message, ... ).
> JMSXDeliveryCount  is actualy used in correlation with field: 'redeliveryCounter'.
> But RedeliveryCounter  field is used to be incremented each time the message is preteched
or sent to a consumer => It does not mean that message has been processed by business in
transaction with a failure. It just has been prefetched by consumer ou subscriber. 
> A 'not consumed message' can be give back to the broker when the consumer is closed by
user, because it has been prefetched but not really consumed!
> It does not match the meaning of the JMS field JMSXDeliveryCount  :
> "If a failure occurs within transactional processing then the JMSXDeliveryCount is incremented".
> JMSXDeliveryCount  field only has to be incremented on rollback (isn't it? ). This is
why Message.redeliveryCount can not be used. Or the behavour of field Message.redeliveryCount
has to be changed.
> You can either :
> * create a new counter on message incremented only on rollback, or
> * modify classes : and to remove redeliveryCount
increment and increment it only on rollback.
> *
>                     if (inAckRange) {
> //                        node.incrementRedeliveryCounter();
>                         if (ack.getLastMessageId().equals(messageId)) {
>                             destination = node.getRegionDestination();
>                             callDispatchMatched = true;
>                             break;
>                         }
>                     }
> *
>                 for (MessageReference ref : sub.remove(context, this)) {
>                     QueueMessageReference qmr = (QueueMessageReference)ref;
> //                    qmr.incrementRedeliveryCounter();
>                     if( qmr.getLockOwner()==sub ) {
>                         qmr.unlock();
> //                        if (!qmr.isDropped() && !qmr.isAcked()) {
> //                        	qmr.incrementRedeliveryCounter();
> //                        }
>                     }
>                     list.add(qmr);
>                 }
> BTW, In this code it seems there is a second bug, in case of  test "qmr.getLockOwner()==sub"
is true qmr is incremented a second time ?! Is it right ?
> The result of this problem is the following: 
> With Spring and DefaultMessageListenerContainer, a message is consumed one by one. This
is why a message prefteched many times, on first real consuming has a JMSXDeliveryCount  with
high value not reflecting the reality.

This message was sent by Atlassian JIRA

View raw message