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 2009/04/11 01:25:14 UTC
[jira] Assigned: (QPID-1791) NonTransactional Sessions can
dequeueandDelete a queueEntry twice
[ https://issues.apache.org/jira/browse/QPID-1791?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Martin Ritchie reassigned QPID-1791:
------------------------------------
Assignee: Martin Ritchie
> NonTransactional Sessions can dequeueandDelete a queueEntry twice
> -----------------------------------------------------------------
>
> Key: QPID-1791
> URL: https://issues.apache.org/jira/browse/QPID-1791
> Project: Qpid
> Issue Type: Bug
> Components: Java Broker
> Affects Versions: M4
> Reporter: Martin Ritchie
> Assignee: Martin Ritchie
>
> Summary:
> When a consumer closes the connection any unacknowledged messages are removed from the map and then re-queued.
> If the queue was temporary then it will have been deleted and our current approach is to delete the message.
> However, in the NonTransactional context the way we process single Acks is not thread safe.
> We first of all perform a get from the unacknowledgeMessageMap do the acknowledgement and then remove it.
> So the sequence of the ack thread is.
> unackedMap.get(messageID)
> dequeueAndDelete(queueEntry for MessageID)
> unackedMap.remove(messageID)
> Whilst the get and remove take the lock on the unackedMap the lack of lock between the two calls allows the ConnectionClose thread to call unackedMap.cancelAllMessages() to return the message that have not been acked.
> This could include the message that is currently being processed by the ack thread.
> It is difficult to see why the get is being used here. There is no code that attempts any error handling if the dequeueAndDelete fails other than simply not performing the remove.
> Replacing the get with a remove should solve this problem. However, there is the question of what to do in the case of a failure in dequeueAndDelete
> The deleteAndDequeue should not normally fail and when it does it signifies a severe broker condition. If we are wanting to attempt dequeueAndDelete and only remove the message from the map if the dequeueAndDelete is successful then we need to perform this action with the unackedMap lock so that we can only ack one message from the session at a time.
> This would have a performance impact. However, I don't believe that this is something we need to do, swapping get with remove should be all we need to do here.
--
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