[
https://issues.apache.org/activemq/browse/AMQCPP-186?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=43974#action_43974
]
Timothy Bish commented on AMQCPP-186:
-------------------------------------
Even if you did that you'd still have to do it at the client as the broker
can't account for the time a message spends in transmission or the time it sits
in the client's dispatch queue before being dispatched. So in either case
there are still going to be several clocks involved, so a more optimal solution
would be to use NTP to sync the clocks and the client and broker machines if
you require the message TLL processing to be accurate.
As it stands this is not an ActiveMQ-CPP issue though so I'm going to close it
here, you are free to open an issue on the broker if you think it appropriate.
> 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.
