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.

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.

> 
> 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,
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.

> 
> I think a better solution would therefore be to have a getCreationTime() 
> in Message::Encoding and for the 0-10 encoding pull the timestamp out 
> the delivery properties if there, and for 1.0 use the creation time.
> 
> That way the implementation will be compliant with both AMQP and JMS 
> when using 1.0, and compliant with JMS when using 0-10.

I agree (I haven't closed the bug because there are still loose ends
like this).

Adding these comments to the bug itself too will be helpful.

Andrew



---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org
For additional commands, e-mail: dev-h...@qpid.apache.org

Reply via email to