You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@qpid.apache.org by "Siddhesh Poyarekar (JIRA)" <qp...@incubator.apache.org> on 2010/03/18 07:46:27 UTC
[jira] Created: (QPID-2454) [Patch] Messages set with a TTL expire
immediately when sent on qpid queues with LVQ ordering
[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
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-subscribe@qpid.apache.org
[jira] Commented: (QPID-2454) [Patch] Messages set with a TTL
expire immediately when sent on qpid queues with LVQ ordering
Posted by "Carl Trieloff (JIRA)" <qp...@incubator.apache.org>.
[ https://issues.apache.org/jira/browse/QPID-2454?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12850282#action_12850282 ]
Carl Trieloff commented on QPID-2454:
-------------------------------------
Committed revision 928003.
Leaving it open as Gordon had mentioned an additional case he wanted to test out.
Carl.
> [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-subscribe@qpid.apache.org
[jira] Resolved: (QPID-2454) [Patch] Messages set with a TTL expire
immediately when sent on qpid queues with LVQ ordering
Posted by "Gordon Sim (JIRA)" <qp...@incubator.apache.org>.
[ 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-subscribe@qpid.apache.org
[jira] Updated: (QPID-2454) [Patch] Messages set with a TTL expire
immediately when sent on qpid queues with LVQ ordering
Posted by "Siddhesh Poyarekar (JIRA)" <qp...@incubator.apache.org>.
[ 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-subscribe@qpid.apache.org
[jira] Commented: (QPID-2454) [Patch] Messages set with a TTL
expire immediately when sent on qpid queues with LVQ ordering
Posted by "Carl Trieloff (JIRA)" <qp...@incubator.apache.org>.
[ https://issues.apache.org/jira/browse/QPID-2454?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12850247#action_12850247 ]
Carl Trieloff commented on QPID-2454:
-------------------------------------
I confirmed this issues is not present anywhere else in the Queue.
> [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-subscribe@qpid.apache.org