On 07/05/2013 07:26 PM, Andrew Stitcher wrote:
On Fri, 2013-07-05 at 17:41 +0100, Gordon Sim wrote:
On 07/05/2013 05:06 PM, astitc...@apache.org wrote:
Author: astitcher
Date: Fri Jul 5 16:06:14 2013
New Revision: 1500052
URL: http://svn.apache.org/r1500052
Log:
QPID-4627: Implement most of the remaining selector special identifiers
Implemented:
message_id, correlation_id,
jms_type, creation_time, absolute_expiry_time
The creation_time property is currently
implemented as the time the message was put on the queue (if enabled
in the broker) as amqp 0_10 has no standard way to indicate the
creation time and we're not currently holding the creation time for amqp 1.0
messages.
Not sure what you mean by 'not holding'. The creation time is set by the
client, not the broker (since it is in the bare message).
I mean that the amqp/Message class currently ignores the creation-time,
even if one is set.
Well, it hasn't needed it until now. It is a matter of a line or two to
record it while parsing though. The hooks are already there, just need
to hold onto the value.
I was a little unsure whether the correct behaviour would be to use the
creation-time as the queue timestamp or to keep it separate. It would
make sense to use the creation time as the queue timestamp because the
expiry time is calculated from it and the supplied ttl, and logically
the expiry time is really the *creation-time* + the ttl. On the other
hand there may be a specific reason to want the queued time separately
from the creation time.
I would keep it separate. Clients are not obliged to set the creation
time, even when using ttl and having each intermediary reduce the ttl
when seeming it out based on the time at which it was received avoids
issues with out of sync clocks (and is what the spec states also).
JMSTimestamp is 'the time a message was handed off to a provider to be
sent. It is not the time the message was actually transmitted because
the actual send may occur later due to transactions or other client side
queueing of messages.'
It looks like the JMS client sends JMSTimestamp in the timestamp field
of delivery-properties over 0-10 (though the 0-10 spec does say that is
set on the server).
Ok, I only looked at the amqp 0-10 classes and didn't find it there,
Didn't find what? The timestamp? If so its in the delivery-properties.
perhaps we should modify the c++ client to do the same, that would make
a lot of sense even if it is not strictly according to the standard.
The c++ client doesn't have a timestamp header. You can set the
creation-time when sending over AMQP 1.0 with x-amqp-creation-time.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org
For additional commands, e-mail: dev-h...@qpid.apache.org
