[
https://issues.apache.org/jira/browse/QPID-1791?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Martin Ritchie updated QPID-1791:
---------------------------------
Status: Ready To Review (was: In Progress)
> 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-subscr...@qpid.apache.org
