[ https://issues.apache.org/jira/browse/QPID-2454?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Siddhesh Poyarekar updated QPID-2454: ------------------------------------- Attachment: qpidc-clear-lvq-on-expire.patch Attached patch clears the lvq messages from the Queue::lvq map when that message has expired. > [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