[
https://issues.apache.org/jira/browse/QPID-2454?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Justin Ross updated QPID-2454:
------------------------------
Assignee: Carl Trieloff
> [Patch] Messages set with a TTL expire immediately when sent on qpid queues
> with LVQ ordering
> ---------------------------------------------------------------------------------------------
>
> Key: QPID-2454
> URL: https://issues.apache.org/jira/browse/QPID-2454
> Project: Qpid
> Issue Type: Bug
> Components: C++ Broker
> Affects Versions: 0.5, 0.6, 0.7
> Environment: RHEL-5 or later
> Reporter: Siddhesh Poyarekar
> Assignee: Carl Trieloff
> Labels: broker, cpp, lvq, queue, ttl
> Attachments: qpidc-clear-lvq-on-expire.patch
>
>
> Problem Description:
> MRG LVQ becomes unstable when msg TTLs are used and a message expires.
> Sometimes when messages expire, it seems to upset the LVQ mechanism. Eg.
> Once a message with key 'X' has expired, any subsequent messages sent to the
> LVQ with key 'X' are expired immediately, and never made available to client
> applications. Once an LVQ begins exhibiting this behaviour, This behaviour
> continues until the broker is restarted. At this point, another side effect
> is that the msgDepth and byteDepth properties on an LVQ do not always agree,
> i.e, when msgDepth is zero, byteDepth is not zero.
> How Reproducible:
> Always:
> Steps to Reproduce:
> * Create a queue with queue ordering as lvq or lvq-no-browse
> * Build and run attached producer for 1 minute
> * Stop the producer for a minute to allow messages to expire
> * Use qpid-tool to monitor the queue depth and wait for the message to be
> dequeued (usually takes about 10 minutes)
> * Once message has expired, restart the producer
> * Watch queue properties with qpid-tool
> Actual Results:
> The queue depth is always 0, but the byte depth is not. Occasionally, one
> will get the following error message from the producer:
> Unexpected exception: Attempted size underflow on dequeue
> Expected Results:
> The queue depth should not be 0 (at least till the time expired messages are
> purged). Also, when queue depth is 0, byte depth should be 0.
> Additional Information:
> The root cause seems to be that the lvq object in the Queue that holds
> mapping from key to messages (Queue::lvq) is not cleared when messages are
> expired (Queue::purgeExpired), which leads to incorrect accounting when the
> next message arrives in the queue with the same LVQ key as the message that
> expired.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
