On Thu, Feb 11, 2010 at 4:51 PM, Kerry Bonin <kerrybo...@gmail.com> wrote:
> I can understand if messages live some reasonable interval past their TTL
> expiration, especially if it is a broker configurable argument.  In our
> case, some developers wanted to set the TTL explicitly to 30 seconds, then
> saw their messages persist overnight, which meant something wasn't working
> as expected, hence my JIRA...
>
> On the subject of default settings (and those broker config settings, thanks
> for them, btw, hadn't seen that option yet) is we are experiencing quite a
> challenge with the 'state' of the documentation.  Other areas of concern
> include the JSON dictionary like arguments on queue creation.  I've seen
> docs appearing in the 'book' folder, need to look there more, but as a
> developer I wish there was a consistent place I could find accurate docs,
> and point my team to.  If this was a wiki I'd be happy to contribute myself,
> as I discover things in the code that I think should be in the docs...

Kerry I understand and share you concerns about the documentation.
Currently it's all over the wiki and most often than not out of sync
with the code.
**We are addressing this on a priority basis**.
The first step is to get the documentation living in svn alongside
code, which we have already started.
Jonathan is working on getting our existing wiki based docs ported
into doc book format.
This will go a long way in ensuring we have proper documentation for
each release.
Our goal is to release documentation along with bits and host them in
our website indexed by release version.
We hope to have this in place before the next release.

I really appreciate your desire to contribute documentation.
I would encourage you to wait bit, until Jonathan gets a chance to
port all the existing docs into documentation (which should be soon).
Then you could have a look at the docs and any updates, improvements
could be attached to the JIRA as a patch.
This process allows us to accept contributions in a legal way and also
make it more easy for folks to contribute and the developers to
incorporate them.

Rajith

> On Thu, Feb 11, 2010 at 11:59 AM, Alan Conway <acon...@redhat.com> wrote:
>
>> On 02/10/2010 02:54 PM, Kerry Bonin wrote:
>>
>>> I just validated a report from a few of my developers that TTL doesn't
>>> seem
>>> to be working with the 0.6 broker, is anyone working on this ?  If not I
>>> can
>>> have a look.  If it does work I'd like to compare notes to see what we're
>>> doing wrong...  Thx!
>>>
>>> (may be QPID-1418, QPID-1575 ?)
>>>
>>> This has been seen by my Python developer using 0.5 api w/ 0.6 broker, and
>>> I
>>> just saw in 0.6 trunk C++ using Messaging.  In the C++ I'm creating w/
>>> type:topic, calling qpid::messaging::Message.setTTL( TIME_SEC * 2 ), and
>>> never see the events go away.  Not sure if this is a broker issue or a
>>> messaging issue...
>>>
>>>
>> Messages are not deleted immediately when their TTL expires. There are two
>> ways TTL messages can get dropped on the broker. If a consumer is looking
>> for the next message on a queue, any stale messages at the front of the
>> queue are dropped. There is also a periodic cleanup operation that removes
>> stale messages from the queue but the default interval is 10 minutes. You
>> can set a smaller interval in seconds with the --queue-purge-interval option
>> or config file setting.
>>
>> If your main concern with TTL is ensuring stale messages don't reach
>> consumers then the default settings are fine. If your main concern is
>> limiting the size of queues in memory you probably want a smaller interval.
>> The periodic cleanup operation currently involves a linear sweep of all
>> queues with TTL messages so there may be some impact on performance during
>> the sweep if you have a lot of deep queues.
>>
>>
>



-- 
Regards,

Rajith Attapattu
Red Hat
http://rajith.2rlabs.com/

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

Reply via email to