[
https://issues.apache.org/jira/browse/AMQ-5406?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14180311#comment-14180311
]
Tim Bain commented on AMQ-5406:
-------------------------------
For the record, the behavior of not checking message expiration on the consumer
(and the fact that Stomp has implemented it that way) are not good per se,
contrary to what Fred wrote in the description. There are situations (such as
high-latency connections between brokers and consumers or consumers that have
built up a prefetch buffer that takes a long time to work off) where messages
on the consumer might be expired (and should not be processed) even when the
consumer's and the broker's clocks are perfectly in sync, and it is for those
reasons that the current checks exist. (And *that* is good.) The ability to
disable those checks for those situations where a consumer knows that their
clock will be out of sync is very useful and that it should be implemented, but
the "correct" behavior is to perform the checks on the consumer side unless
there's a reason not to, and it should remain the default behavior.
> Support of jms.consumerExpiryCheck=false to avoid JMS Consumers ignoring some
> messages in case of out-of-synch clocks
> ---------------------------------------------------------------------------------------------------------------------
>
> Key: AMQ-5406
> URL: https://issues.apache.org/jira/browse/AMQ-5406
> Project: ActiveMQ
> Issue Type: Improvement
> Components: JMS client
> Affects Versions: 5.9.0, 5.9.1, 5.10.0
> Reporter: Fred Moore
>
> AS IS
> JMS Consumer re-checks messages served to him by the Broker and ignores those
> appearing to be expired according to the clock on the Consumer machine.
> TO BE
> Allow Consumer to optionally disable this check and blindly trust the
> expirations check already performed at the Broker, according to the broker
> clock.
> RATIONALES
> When the Consumer clock is running ahead of the Broker clock by more that the
> time-to-live of a message, the message would be wrongly ignored by the
> consumer.
> Please notice that in a situation like this BrokerTimestampingPlugin is of no
> help, because it only influence the way messages sent by the Producer are
> handled at the broker, while the issue reported here is Consumer related.
> ADDITIONAL RATIONALES
> 1\ STOMP API does NOT perform expiration re-checks at the consumer (and this
> is good)
> 2\ .NET API already has an option as the one request here and for similar
> reasons
> BACKGROUND DISCUSSION
> Here are some snippets of the background discussion on
> [email protected] list, where this request has been informally
> seconded by Gary Tully & Timothy Bish (thanks guys!):
> http://mail-archives.apache.org/mod_mbox/activemq-users/201410.mbox/%3ccange49cknm-6_diywvttdfgazpj2sjomc3ypjf7k+vsbdou...@mail.gmail.com%3E
> http://mail-archives.apache.org/mod_mbox/activemq-users/201410.mbox/%3CCAFitrpQJK4MukyJ5yxPb=ygqnc0yv5jetgwiesxu8bqagfs...@mail.gmail.com%3E
> http://mail-archives.apache.org/mod_mbox/activemq-users/201410.mbox/%3ccange49c0xok732urrzkax0__h9xvqjys_7aue5ysh0um+4f...@mail.gmail.com%3E
> http://mail-archives.apache.org/mod_mbox/activemq-users/201410.mbox/%3CCAH+vQmPtedrsomaZsvzU+eksLEm6GGeO5p=qzyptqwb7arv...@mail.gmail.com%3E
> http://mail-archives.apache.org/mod_mbox/activemq-users/201410.mbox/%[email protected]%3E
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
