qpid-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Robert Godfrey <rob.j.godf...@gmail.com>
Subject Re: LVQ and message TTL
Date Wed, 08 Sep 2010 10:06:24 GMT
On 8 September 2010 08:34, Gordon Sim <gsim@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


Mime
View raw message