You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@qpid.apache.org by Gordon Sim <gs...@redhat.com> on 2013/07/05 18:41:08 UTC
Selectors and JMSTimestamp/creation-time (was Re: svn commit: r1500052
- in /qpid/trunk/qpid/cpp/src/qpid: amqp/ broker/ broker/amqp/ broker/amqp_0_10/)
On 07/05/2013 05:06 PM, astitcher@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).
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).
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.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@qpid.apache.org
For additional commands, e-mail: dev-help@qpid.apache.org
Re: Selectors and JMSTimestamp/creation-time (was Re: svn commit:
r1500052 - in /qpid/trunk/qpid/cpp/src/qpid: amqp/ broker/ broker/amqp/ broker/amqp_0_10/)
Posted by Gordon Sim <gs...@redhat.com>.
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, astitcher@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-unsubscribe@qpid.apache.org
For additional commands, e-mail: dev-help@qpid.apache.org
Re: Selectors and JMSTimestamp/creation-time (was Re: svn commit:
r1500052 - in /qpid/trunk/qpid/cpp/src/qpid: amqp/ broker/ broker/amqp/
broker/amqp_0_10/)
Posted by Andrew Stitcher <as...@redhat.com>.
On Fri, 2013-07-05 at 17:41 +0100, Gordon Sim wrote:
> On 07/05/2013 05:06 PM, astitcher@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-unsubscribe@qpid.apache.org
For additional commands, e-mail: dev-help@qpid.apache.org