[jira] [Commented] (AMQ-5406) Support of jms.consumerExpiryCheck=false to avoid JMS Consumers ignoring some messages in case of out-of-synch clocks

["Tim Bain (JIRA)" <ji...@apache.org>]

    [ 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 users@activemq.apache.org 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+VsBdoUaVA@mail.gmail.com%3E
> http://mail-archives.apache.org/mod_mbox/activemq-users/201410.mbox/%3CCAFitrpQJK4MukyJ5yxPb=ygQnC0yV5jetgWiesxu8BqagfSScQ@mail.gmail.com%3E
> http://mail-archives.apache.org/mod_mbox/activemq-users/201410.mbox/%3CCANGe49c0Xok732URRZKAx0__H9XVqjys_7auE5ysH0um+4fZkQ@mail.gmail.com%3E
> http://mail-archives.apache.org/mod_mbox/activemq-users/201410.mbox/%3CCAH+vQmPtedrsomaZsvzU+eksLEm6GGeO5p=QzYPtqwB7ArvgAw@mail.gmail.com%3E
> http://mail-archives.apache.org/mod_mbox/activemq-users/201410.mbox/%3C5447BF6F.1090103@gmail.com%3E



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