You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@qpid.apache.org by Toralf Lund <to...@pgs.com> on 2016/01/19 15:19:59 UTC
getTtl() behaviour (C++ messaging API)
Hi,
I have some questions about the value from qpid::messaging::Message::getTtl() on received messages; based on testing, I've concluded that
1. The value returned represents the time that remains of the time-to-live specified by the sender.
2. If no TTL was set, the value is qpid::messaging::Duration::IMMEDIATE, which is equivalent to 0.
Is this correct? If it is, when exactly does the count-down occur? And when does the clock stop, so as to speak? When I call fetch(), or when the message is pre-fetched by the receiver, or at some other point? Also, can I always assume there is no real time-to-live if qpid::messaging::Duration::IMMEDIATE is returned, or could I also get that value because the message was about to expire when it was fetched?
Thanks,
- Toralf
[http://www.pgs.com/mediaFiles/Exclaimer%20graphics/PGS_LOGO_RGB_42x53px.jpg]<http://www.pgs.com> Toralf Lund
Senior Software Engineer
Imaging & Engineering | Geoscience & Engineering
Telephone: +47 67 52 64 00
Direct: +47 67 51 57 78
VOIP: 74715778
Mobile: +47 91 31 66 91
Email: toralf.lund@pgs.com<ma...@pgs.com>
A Clearer Image | www.pgs.com<http://www.pgs.com>
[http://www.pgs.com/mediaFiles/Exclaimer%20graphics/150731-ColourWave-660x14px.jpg]
Address: Lilleakerveien 4C, 0283 Oslo, Norway
Postal Address: P.O.Box 251 Lilleaker, 0216 Oslo, Norway
This e-mail, including any attachments and response string, may contain proprietary information which is confidential and may be legally privileged. It is for the intended recipient only. If you are not the intended recipient or transmission error has misdirected this e-mail, please notify the author by return e-mail and delete this message and any attachment immediately. If you are not the intended recipient you must not use, disclose, distribute, forward, copy, print or rely on this e-mail in any way except as permitted by the author.
Re: getTtl() behaviour (C++ messaging API)
Posted by Gordon Sim <gs...@redhat.com>.
On 01/20/2016 12:29 PM, Toralf Lund wrote:
> On 19/01/16 17:01, Gordon Sim wrote:
>> The value reported for received messages is that value that was
>> written to the wire by the peer (e.g. the broker). The receiving
>> client does not reduce this value in anyway after the message has been
>> decoded.
> So, in other words, the value relates to the time Receiver::fetch() was
> called on a receiver with capacity 0, and the point where the receiver
> got the message "in the background" if capacity is >0?
The value relates to the time the broker sent it. Generally that would
indeed only be milliseconds at most earlier than the point at which the
client receives it though.
> How exactly does the prefetch work, by the way? Will the client still
> ask for messages individually, or does it tell the broker in advance
> that it's prepared to receive a certain number of messages?
If you set a capacity > 0, then the client will tell the broker it is
prepared to handle that many messages. It will then move that window
forward as messages are received.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@qpid.apache.org
For additional commands, e-mail: users-help@qpid.apache.org
Re: getTtl() behaviour (C++ messaging API)
Posted by Toralf Lund <to...@pgs.com>.
On 19/01/16 17:01, Gordon Sim wrote:
> On 01/19/2016 02:19 PM, Toralf Lund wrote:
>> Hi,
>>
>> I have some questions about the value from
>> qpid::messaging::Message::getTtl() on received messages; based on
>> testing, I've concluded that
>>
>> 1. The value returned represents the time that remains of the
>> time-to-live specified by the sender.
>> 2. If no TTL was set, the value is
>> qpid::messaging::Duration::IMMEDIATE, which is equivalent to 0.
>
> That is a bit unfortunate.
Yes. I sort of expected qpid::messaging::Duration::FOREVER...
>
>> Is this correct? If it is, when exactly does the count-down occur? And
>> when does the clock stop, so as to speak? When I call fetch(), or when
>> the message is pre-fetched by the receiver, or at some other point?
>
> The value reported for received messages is that value that was
> written to the wire by the peer (e.g. the broker). The receiving
> client does not reduce this value in anyway after the message has been
> decoded.
So, in other words, the value relates to the time Receiver::fetch() was
called on a receiver with capacity 0, and the point where the receiver
got the message "in the background" if capacity is >0?
How exactly does the prefetch work, by the way? Will the client still
ask for messages individually, or does it tell the broker in advance
that it's prepared to receive a certain number of messages?
>
>> Also, can I always assume there is no real time-to-live if
>> qpid::messaging::Duration::IMMEDIATE is returned, or could I also get
>> that value because the message was about to expire when it was fetched?
>
> If the ttl was 0 at the point the peer was encoding it, I would
> generally expect the message not to be sent at all. Therefore I would
> not expect a message to be read from the wire with ttl=0 and so at
> present I think you can treat IMMEDIATE as implying no ttl (as ugly as
> that is).
Fair enough. I can work with that.
Thanks!
- Toralf
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@qpid.apache.org
> For additional commands, e-mail: users-help@qpid.apache.org
>
[http://www.pgs.com/mediaFiles/Exclaimer%20graphics/PGS_LOGO_RGB_42x53px.jpg]<http://www.pgs.com> Toralf Lund
Senior Software Engineer
Imaging & Engineering | Geoscience & Engineering
Telephone: +47 67 52 64 00
Direct: +47 67 51 57 78
VOIP: 74715778
Mobile: +47 91 31 66 91
Email: toralf.lund@pgs.com<ma...@pgs.com>
A Clearer Image | www.pgs.com<http://www.pgs.com>
[http://www.pgs.com/mediaFiles/Exclaimer%20graphics/150731-ColourWave-660x14px.jpg]
Address: Lilleakerveien 4C, 0283 Oslo, Norway
Postal Address: P.O.Box 251 Lilleaker, 0216 Oslo, Norway
This e-mail, including any attachments and response string, may contain proprietary information which is confidential and may be legally privileged. It is for the intended recipient only. If you are not the intended recipient or transmission error has misdirected this e-mail, please notify the author by return e-mail and delete this message and any attachment immediately. If you are not the intended recipient you must not use, disclose, distribute, forward, copy, print or rely on this e-mail in any way except as permitted by the author.
Re: getTtl() behaviour (C++ messaging API)
Posted by Gordon Sim <gs...@redhat.com>.
On 01/19/2016 02:19 PM, Toralf Lund wrote:
> Hi,
>
> I have some questions about the value from
> qpid::messaging::Message::getTtl() on received messages; based on
> testing, I've concluded that
>
> 1. The value returned represents the time that remains of the
> time-to-live specified by the sender.
> 2. If no TTL was set, the value is
> qpid::messaging::Duration::IMMEDIATE, which is equivalent to 0.
That is a bit unfortunate.
> Is this correct? If it is, when exactly does the count-down occur? And
> when does the clock stop, so as to speak? When I call fetch(), or when
> the message is pre-fetched by the receiver, or at some other point?
The value reported for received messages is that value that was written
to the wire by the peer (e.g. the broker). The receiving client does not
reduce this value in anyway after the message has been decoded.
> Also, can I always assume there is no real time-to-live if
> qpid::messaging::Duration::IMMEDIATE is returned, or could I also get
> that value because the message was about to expire when it was fetched?
If the ttl was 0 at the point the peer was encoding it, I would
generally expect the message not to be sent at all. Therefore I would
not expect a message to be read from the wire with ttl=0 and so at
present I think you can treat IMMEDIATE as implying no ttl (as ugly as
that is).
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@qpid.apache.org
For additional commands, e-mail: users-help@qpid.apache.org