I received no objections, and a number of expressions of support, so I have now gone ahead and changed the definition of
the new JMSDeliveryTime message property to be "the difference, measured in milliseconds, between the delivery time and
midnight, January 1, 1970 UTC."
I have also gone ahead and made the same change to the existing JMSExpiration property. This separate change is covered
by
http://java.net/jira/browse/JMS_SPEC-82 . I think it is unlikely that an existing provider will have used a method
other than System.currentTimeMillis() to obtain the current time as a long. However if we receive any objections we can
make this definition a non-mandatory recommendation.
Please see updated spec sections:
Section 3.4.9 "JMSExpiration" and section 4.8 "Message time-to-live"
Section 3.4.13 "JMSDeliveryTime" and section 4.12 "Delivery delay"
Updated API documentation for the Message methods getJMSExpiration and getJMSDeliveryTime
Links to the latest draft specification and API docs can be found here:
http://java.net/projects/jms-spec/pages/Home#Latest_draft_specification_and_javadocs
Nigel
On 10/09/2012 12:51, Nigel Deakin wrote:
> On 07/09/2012 23:40, Chris Barrow wrote:
>> Hi Nigel,
>>
>> In #1 I think you meant JMSDeliveryTime.
>
> Yes, indeed I did. Here's the corrected text:
>
> I propose to clarify the definition of the new JMSDeliveryTime message property to be "the difference, measured in
> milliseconds, between the delivery time and midnight, January 1, 1970 UTC."
>
>> I agree with your proposals, and clarity is good! Perhaps for #2 (JMSExpiration) the spec could use the word SHOULD
>> rather than MUST if must would be too strict for certain existing behaviors.
>
> That's a possibility (though I would prefer to use the words "is recommended to" when mentioning non-mandatory
> behaviour). Any other views? Mandatory / recommended / no change?
>
> This proposal is whether we can clarify the definition of the JMSExpiration message property to be "the difference,
> measured in milliseconds, between the expiry time and midnight, January 1, 1970 UTC"
>
>> However, on the other hand one could argue
>> that since this is a major release of the JMS spec some backward incompatibility might be permissible. But it sounds as
>> if you have a strictly forward compatible philosophy here.
>
> If the existing spec had unambiguously defined JMSExpiration then we should definitely not change the definition to
> something else. But since it is currently defined somewhat vaguely we have a certain amount of scope to replace it with
> a less vague definition, if we think this is appropriate.
>
> Nigel
>
>
>> Chris
>>
>> On 9/7/2012 8:53 AM, Nigel Deakin wrote:
>>> Whilst updating the API docs for delivery delay I had one small additional thought on delivery delay.
>>>
>>> Currently the JMSDeliveryTime message property is defined as "the sum of the message's delivery delay and the GMT it
>>> is sent".
>>>
>>> I chose this wording to keep it consistent with the definition of the JMSExpiration message property, which is "the
>>> sum of the time-to-live value specified by the client and the GMT at the time of the send"
>>>
>>> However since in both cases these property are long values (rather than Date values) and so this is rather ambiguous
>>> as it does not specify how the actual delivery time is converted to a long.
>>>
>>> Since JMSDeliveryTime is a new property we are free to define it however we like. I would like to suggest that we
>>> define it as being defined as "the difference, measured in milliseconds, between the delivery time and midnight,
>>> January 1, 1970 UTC".
>>>
>>> This means a JMS provider could set the delivery time header at the time of the send by adding the delivery delay to
>>> System.currentTimeMillis().
>>>
>>> It would be nice if we could clarify the definition of JMSExpiration in a similar manner, but since this is an old
>>> property we may have to leave the definition vague in case a current JMS provider currently uses a different
>>> implementation and applications rely on it.
>>>
>>> So:
>>>
>>> 1. I propose to clarify the definition of the new JMSExpiration message property to be "the difference, measured in
>>> milliseconds, between the delivery time and midnight, January 1, 1970 UTC". Any comments?
>>>
>>> 2. I'd like to invite views on whether it is desirable to, and also safe to, change the definition of JMSExpiration in
>>> a similar manner. If we're not sure I will leave this unchanged.
>>>
>>> Nigel
>>