qpid-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Martin Ritchie (JIRA)" <qpid-...@incubator.apache.org>
Subject [jira] Commented: (QPID-1136) Broker does not correctly remove persistent message data for the store when acking messages.
Date Fri, 13 Jun 2008 16:18:46 GMT

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

View raw message