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