[
https://issues.apache.org/jira/browse/QPID-2454?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Gordon Sim resolved QPID-2454.
------------------------------
Resolution: Fixed
Clearly more tests are needed in this area, but no reason not to mark this bug
fixed now change has been made.
> [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
> 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.
-
You can reply to this email to add a comment to the issue online.
---------------------------------------------------------------------
Apache Qpid - AMQP Messaging Implementation
Project: http://qpid.apache.org
Use/Interact: mailto:dev-subscr...@qpid.apache.org
