[
https://issues.apache.org/activemq/browse/AMQCPP-186?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=43949#action_43949
]
Timothy Bish commented on AMQCPP-186:
-------------------------------------
>From the JMS API
bq. SetTimeToLive - Sets the default length of time in milliseconds from its
dispatch time that a produced message should be retained by the message system.
bq. getJMSExpiration - When a message is sent, the JMSExpiration header field
is left unassigned. After completion of the send or publish method, it holds
the expiration time of the message. This is the sum of the time-to-live value
specified by the client and the GMT at the time of the send or publish.
This implies that clock drift could cause you to lose messages on the client
machines, or inversely not tag them as expired when they actually are.
> CMSExpiration computed incorrectly (?)
> --------------------------------------
>
> Key: AMQCPP-186
> URL: https://issues.apache.org/activemq/browse/AMQCPP-186
> Project: ActiveMQ C++ Client
> Issue Type: Bug
> Affects Versions: 2.1.3
> Reporter: Eddie Epstein
> Assignee: Nathan Mittler
>
> The C++ consumer is treating messages as expired in situations where the Java
> consumer is not.
> It could be that the problem is due to the code in
> connector/openwire/commands/ActiveMQMessageBase.h which compares the
> CMSExpiration time specified by producer.setTimeToLive() with the local
> clock on the consumer machine.
> /**
> * Returns if this message has expired, meaning that its
> * Expiration time has elapsed.
> * @returns true if message is expired.
> */
> virtual bool isExpired() const {
> long long expireTime = this->getCMSExpiration();
> long long currentTime =
> decaf::util::Date::getCurrentTimeMilliseconds();
> if( expireTime > 0 && currentTime > expireTime ) {
> return true;
> }
> return false;
> }
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
