Mailing-List: contact users-help@qpid.apache.org; run by ezmlm
Precedence: bulk
Reply-To: users@qpid.apache.org
Received-SPF: pass (nike.apache.org: domain of rob.j.godfrey@gmail.com
 designates 209.85.216.177 as permitted sender)
DomainKey-Signature: a=rsa-sha1; c=nofws;
        d=gmail.com; s=gamma;
        h=mime-version:in-reply-to:references:date:message-id:subject:from:to
         :content-type:content-transfer-encoding;
        b=TDf6vPViFIXEqS+AOYc4sK6XsMGHY5ReSIUhLtREN/HNf7sZf1MYQD/JmP0e+HnLsH
         zxCg64vUpQn7J43gz8g5NoYLscp3C9SU5JNKZ4MlFxA1TejrLE0w9P2vhoqzo5Xarjxr
         IZpv3iwH7hXLsNe30MFGUiRHfxNoeUzfa/IR4=
MIME-Version: 1.0
In-Reply-To: <4C872E69.7010106@redhat.com>
References: <AANLkTikpVPQ0Q2AwJKs4DZCBjNjSMpkazCHhvspNEwvL@mail.gmail.com>
	<4C872E69.7010106@redhat.com>
Date: Wed, 8 Sep 2010 12:06:24 +0200
Message-ID: <AANLkTi=vr_Au+gvFg3SZb_Azpv79-eGqF8hsp=B1t3NH@mail.gmail.com>
Subject: Re: LVQ and message TTL
From: Robert Godfrey <rob.j.godfrey@gmail.com>
To: users@qpid.apache.org
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

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:
>>
>> =A0* Send a message w/ ttl=3D5 LVQ_key=3Dbar
>> =A0* Send another message w/ ttl=3D3600, LVQ_key=3Dbar
>>
>> 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