[
https://issues.apache.org/jira/browse/QPID-5057?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13739764#comment-13739764
]
Robbie Gemmell commented on QPID-5057:
--------------------------------------
{quote}
1) expiration and timestamp delivery properties sent in proper format (datetime
in seconds, not in ms).
{quote}
0-9-1 does not specify the value should be in seconds (it actually doesnt
specify any units,only that it is "For application use, no formal behaviour")
so it doesn't seem like any change should be made to that section of the client.
The patch divides the ms value by 1000 to convert the units to seconds...is it
not necessary to do the reverse in some cases?
What does the C++ broker do with the provided value, treat it as being in
seconds or milliseconds? I believe the Java broker will treat it as
milliseconds, in which case its 0-10 protocol handling would also need to be
updated, although this would break compatibility with all existing clients <=
0.24, so it might be prudent to try and detect the client/broker versions and
act appropriately.
It would probably also be wise to make it explicitly user configurable, so the
prior behaviour can be restored for compatibility with any existing deployed
brokers <= 0.24.
{quote}
2) ability to re-write timestamp (i.e. set timestamp automatically only if it
hasn't been already set)
{quote}
That seems like an entirely different issue from this JIRA, and if done should
be undertaken separately. It seems questionable since it would mean the client
would only set the timestamp the first time a Message object was sent when it
should normally be updated every time the Message is sent.
> Delivery properties "expiration" and "timestamp" are in milliseconds instead
> of seconds
> ---------------------------------------------------------------------------------------
>
> Key: QPID-5057
> URL: https://issues.apache.org/jira/browse/QPID-5057
> Project: Qpid
> Issue Type: Bug
> Components: Java Client
> Affects Versions: 0.22
> Reporter: Pavel Moravec
> Priority: Minor
> Attachments: bz995079.patch, SendMsgTimestamp.java
>
>
> Per AMQP 0.10 specification, message delivery properties "expiration" and
> "timestamp" are of type datetime, that is 64 bit POSIX time_t format, i.e.
> "seconds since Epoch".
> But Java client implementation of both 0.8 and 0.10 protocol versions encodes
> the properties in milliseconds. See e.g.
> org/apache/qpid/client/BasicMessageProducer_0_10.java:
> long currentTime = 0;
> if (timeToLive > 0 || !isDisableTimestamps())
> {
> currentTime = System.currentTimeMillis();
> }
> if (timeToLive > 0)
> {
> deliveryProp.setTtl(timeToLive);
> message.setJMSExpiration(currentTime + timeToLive);
> }
> if (!isDisableTimestamps())
> {
> deliveryProp.setTimestamp(currentTime);
> message.setJMSTimestamp(currentTime);
> }
> I.e. there should be "currentTime = System.currentTimeMillis()/1000;", rather.
> The same is in 0.8 client as well (while AMQP 0.8 specification does not know
> either of the two delivery properties).
> I could propose a trivial patch for the 0.8 and 0.10 client, but I am not
> sure how this affects:
> - AMQP 1.0 implementation I am not familiar with
> - (Java only?) broker or other clients utilizing the properties
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
