You are viewing a plain text version of this content. The canonical link for it is here.
Posted to issues@activemq.apache.org by "Gary Tully (JIRA)" <ji...@apache.org> on 2016/07/21 12:46:20 UTC

[jira] [Reopened] (AMQ-6361) Message can remain inflight after consumer side expiration acknowledgements

     [ https://issues.apache.org/jira/browse/AMQ-6361?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Gary Tully reopened AMQ-6361:
-----------------------------
      Assignee: Gary Tully  (was: Timothy Bish)

There is a regression in org.apache.activemq.usecases.ExpiredMessagesTest
the problem is that the stats are off b/c the message can get processed twice for expiry. The stats reports too many expired and the dlq rejects the duplicates so the stat and dlq queue size don't match for the assertion.
expiry is one process that has shared access to the message.

peeking at adding method to messageReference to encapsulate the right to process an expired message, such that it is done once.

> Message can remain inflight after consumer side expiration acknowledgements
> ---------------------------------------------------------------------------
>
>                 Key: AMQ-6361
>                 URL: https://issues.apache.org/jira/browse/AMQ-6361
>             Project: ActiveMQ
>          Issue Type: Bug
>          Components: Broker
>    Affects Versions: 5.13.3
>            Reporter: Timothy Bish
>            Assignee: Gary Tully
>             Fix For: 5.14.0
>
>
> If the client clock is slightly ahead of the brokers clock a message could be expired on the client but not considered expired on the broker.
> When the expiry ACK is sent to the broker it checks if the message is also considered expired on the broker side. If the broker clock is behind the client side clock the message could be considered not expired on the broker and not
> removed from the broker's dispatched list. This leaves the broker reporting a message inflight from the broker's perspective even though the message has been expired on the consumer(client) side
> The broker should treat the expired ACK as the authority on whether a message is expired and process it as such regardless of the broker side clock.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)