You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@qpid.apache.org by "Martin Ritchie (JIRA)" <qp...@incubator.apache.org> on 2008/06/12 15:16:45 UTC

[jira] Created: (QPID-1136) Broker does not correctly remove persistent message data for the store when acking messages.

Broker does not correctly remove persistent message data for the store when acking messages.
--------------------------------------------------------------------------------------------

                 Key: QPID-1136
                 URL: https://issues.apache.org/jira/browse/QPID-1136
             Project: Qpid
          Issue Type: Bug
          Components: Java Broker
    Affects Versions: M3
            Reporter: Martin Ritchie
            Assignee: Martin Ritchie
             Fix For: M3


Summary:
When using consuming persistent messages in a non-transactional session the message header and content will be left on the broker after the message has been acknowledged by the client.

The impact will depend on the type of message store in use:

MemoryMessageStore 
The broker will eventually fail with an OutOfMemoryException. 

BDBMemoryStore 
When the broker memory is filled the message data will be pushed to disk causing a temporary slow down of message transfer. Normal throughput will be resumed after the delivery of the messages that were pushed to disk has occurred. This cycle of filling memory and then flushing to disk will continue until the disk fills up causing an exception in the broker. 
Additionally, when the broker is restarted all the messages will be redelivered as they have not been dequeued.

Other persistent store such as DerbyMessageStore:
However the behaviour should be similar to the BDBMemoryStore.


-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.


[jira] Commented: (QPID-1136) Broker does not correctly remove persistent message data for the store when acking messages.

Posted by "Martin Ritchie (JIRA)" <qp...@incubator.apache.org>.
    [ https://issues.apache.org/jira/browse/QPID-1136?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12604922#action_12604922 ] 

Martin Ritchie commented on QPID-1136:
--------------------------------------

Commit change to M2.x and merged on to M2.1.x

> Broker does not correctly remove persistent message data for the store when acking messages.
> --------------------------------------------------------------------------------------------
>
>                 Key: QPID-1136
>                 URL: https://issues.apache.org/jira/browse/QPID-1136
>             Project: Qpid
>          Issue Type: Bug
>          Components: Java Broker
>    Affects Versions: M3
>            Reporter: Martin Ritchie
>            Assignee: Martin Ritchie
>             Fix For: M3
>
>
> Summary:
> When using consuming persistent messages in a non-transactional session the message header and content will be left on the broker after the message has been acknowledged by the client.
> The impact will depend on the type of message store in use:
> MemoryMessageStore 
> The broker will eventually fail with an OutOfMemoryException. 
> BDBMemoryStore 
> When the broker memory is filled the message data will be pushed to disk causing a temporary slow down of message transfer. Normal throughput will be resumed after the delivery of the messages that were pushed to disk has occurred. This cycle of filling memory and then flushing to disk will continue until the disk fills up causing an exception in the broker. 
> Additionally, when the broker is restarted all the messages will be redelivered as they have not been dequeued.
> Other persistent store such as DerbyMessageStore:
> However the behaviour should be similar to the BDBMemoryStore.

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.


[jira] Commented: (QPID-1136) Broker does not correctly remove persistent message data for the store when acking messages.

Posted by "Martin Ritchie (JIRA)" <qp...@incubator.apache.org>.
    [ https://issues.apache.org/jira/browse/QPID-1136?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12604921#action_12604921 ] 

Martin Ritchie commented on QPID-1136:
--------------------------------------

This problem was a result of the change to UnacknowledgedMessage.discard to check that the message is still in the list of unacked msgs before removing it. However, the NonTransactionalalContext removes the messages from the map before discarding them, hence the message content is never dequeued nor is discarded.

> Broker does not correctly remove persistent message data for the store when acking messages.
> --------------------------------------------------------------------------------------------
>
>                 Key: QPID-1136
>                 URL: https://issues.apache.org/jira/browse/QPID-1136
>             Project: Qpid
>          Issue Type: Bug
>          Components: Java Broker
>    Affects Versions: M3
>            Reporter: Martin Ritchie
>            Assignee: Martin Ritchie
>             Fix For: M3
>
>
> Summary:
> When using consuming persistent messages in a non-transactional session the message header and content will be left on the broker after the message has been acknowledged by the client.
> The impact will depend on the type of message store in use:
> MemoryMessageStore 
> The broker will eventually fail with an OutOfMemoryException. 
> BDBMemoryStore 
> When the broker memory is filled the message data will be pushed to disk causing a temporary slow down of message transfer. Normal throughput will be resumed after the delivery of the messages that were pushed to disk has occurred. This cycle of filling memory and then flushing to disk will continue until the disk fills up causing an exception in the broker. 
> Additionally, when the broker is restarted all the messages will be redelivered as they have not been dequeued.
> Other persistent store such as DerbyMessageStore:
> However the behaviour should be similar to the BDBMemoryStore.

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.


[jira] Resolved: (QPID-1136) Broker does not correctly remove persistent message data for the store when acking messages.

Posted by "Martin Ritchie (JIRA)" <qp...@incubator.apache.org>.
     [ https://issues.apache.org/jira/browse/QPID-1136?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Martin Ritchie resolved QPID-1136.
----------------------------------

    Resolution: Fixed

Merged changes from M2 plus a patch from Robert Godfrey and Aidan Skinner to test that the subscriber correctly releases its credit.

> Broker does not correctly remove persistent message data for the store when acking messages.
> --------------------------------------------------------------------------------------------
>
>                 Key: QPID-1136
>                 URL: https://issues.apache.org/jira/browse/QPID-1136
>             Project: Qpid
>          Issue Type: Bug
>          Components: Java Broker
>    Affects Versions: M3
>            Reporter: Martin Ritchie
>            Assignee: Martin Ritchie
>             Fix For: M3
>
>
> Summary:
> When using consuming persistent messages in a non-transactional session the message header and content will be left on the broker after the message has been acknowledged by the client.
> The impact will depend on the type of message store in use:
> MemoryMessageStore 
> The broker will eventually fail with an OutOfMemoryException. 
> BDBMemoryStore 
> When the broker memory is filled the message data will be pushed to disk causing a temporary slow down of message transfer. Normal throughput will be resumed after the delivery of the messages that were pushed to disk has occurred. This cycle of filling memory and then flushing to disk will continue until the disk fills up causing an exception in the broker. 
> Additionally, when the broker is restarted all the messages will be redelivered as they have not been dequeued.
> Other persistent store such as DerbyMessageStore:
> However the behaviour should be similar to the BDBMemoryStore.

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.