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/08/12 18:12:47 UTC

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

     [ 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.