On 8 September 2010 08:34, Gordon Sim <[email protected]> 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:[email protected]
