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