LVQ and message TTL

[Daniel Lundin <dl...@eintr.org>]

I'm playing around with LVQs, in particular in conjunction w/ttl
semantics for expiration of keys/symbols.

I noticed that if I post a message for a given LVQ key, it's not
possible to change its TTL of a key "on the fly".
The TTL of the initial message seems to be the one in effect - even
though browsing the messages will show the latest (incorrect) TTL
value.

To reproduce:

 * Send a message w/ ttl=5 LVQ_key=bar
 * Send another message w/ ttl=3600, LVQ_key=bar

The message will expire and get purged after 5s.

Is this expected behavior? It seems it would be pretty useful and
consistent that the properties of the last posted message are
effective?

/Daniel

PS. Tested on both 0.6 and trunk.

---------------------------------------------------------------------
Apache Qpid - AMQP Messaging Implementation
Project:      http://qpid.apache.org
Use/Interact: mailto:users-subscribe@qpid.apache.org

Re: LVQ and message TTL

[Robert Godfrey <ro...@gmail.com>]

On 8 September 2010 08:34, Gordon Sim <gs...@redhat.com> wrote:
> On 09/07/2010 10:19 PM, Daniel Lundin wrote:
>>
>> I'm playing around with LVQs, in particular in conjunction w/ttl
>> semantics for expiration of keys/symbols.
>>
>> I noticed that if I post a message for a given LVQ key, it's not
>> possible to change its TTL of a key "on the fly".
>> The TTL of the initial message seems to be the one in effect - even
>> though browsing the messages will show the latest (incorrect) TTL
>> value.
>>
>> To reproduce:
>>
>>  * Send a message w/ ttl=5 LVQ_key=bar
>>  * Send another message w/ ttl=3600, LVQ_key=bar
>>
>> The message will expire and get purged after 5s.
>>
>> Is this expected behavior? It seems it would be pretty useful and
>> consistent that the properties of the last posted message are
>> effective?
>
> I agree, the behaviour you describe is not what I would expect. Can you
> raise a bug for that?

I believe the Java Broker has the more expected (correct) behaviour.

I guess a theoretically interesting question is: what should occur if
the message order were reversed, i.e. you send a message with TTL
3600s, followed by a message with the same key and TTL 5s.  One could
plausibly argue that after 5s the value for the given key should
revert to the "original" value.  The Java Broker would not exhibit
this behaviour, but would instead have no value for the given key
after the second version of the message had expired.

-- Rob

---------------------------------------------------------------------
Apache Qpid - AMQP Messaging Implementation
Project:      http://qpid.apache.org
Use/Interact: mailto:users-subscribe@qpid.apache.org

Re: LVQ and message TTL

[Gordon Sim <gs...@redhat.com>]

On 09/07/2010 10:19 PM, Daniel Lundin wrote:
> I'm playing around with LVQs, in particular in conjunction w/ttl
> semantics for expiration of keys/symbols.
>
> I noticed that if I post a message for a given LVQ key, it's not
> possible to change its TTL of a key "on the fly".
> The TTL of the initial message seems to be the one in effect - even
> though browsing the messages will show the latest (incorrect) TTL
> value.
>
> To reproduce:
>
>   * Send a message w/ ttl=5 LVQ_key=bar
>   * Send another message w/ ttl=3600, LVQ_key=bar
>
> The message will expire and get purged after 5s.
>
> Is this expected behavior? It seems it would be pretty useful and
> consistent that the properties of the last posted message are
> effective?

I agree, the behaviour you describe is not what I would expect. Can you 
raise a bug for that?

---------------------------------------------------------------------
Apache Qpid - AMQP Messaging Implementation
Project:      http://qpid.apache.org
Use/Interact: mailto:users-subscribe@qpid.apache.org