Requeuing a message when the message is sent appears to be unnecessary
----------------------------------------------------------------------
Key: QPID-16
URL: http://issues.apache.org/jira/browse/QPID-16
Project: Qpid
Issue Type: Improvement
Reporter: Steven Shaw
Consider the following code in AMQMessage.requeueImpl():
_store.dequeueMessage(queue.getName(), _messageId);
_store.enqueueMessage(queue.getName(), _messageId);
We felt that it made sense because it "puts the message to the back of the
queue" (and that perhaps if the queue on disk is sort or sorted when loaded
then the message order is preserved). We also agreed that this was necessary
because when a message is sent to a NO_ACK consumer, the message is "dequeued"
and that can only be deleted from the end of the queue (i.e. popped).
However, we were wrong on most counts.
When you look at the implementation of AMQMessage.dequeue:
_store.dequeueMessage(queue.getName(), _messageId);
we see that it is able to use the messageId of the message to delete a message
"inside" the queue (i.e. not on the end). There is no requirement to pop it off
one end!
This means that the dequeue and enqueue are not necessary.
Also, it appears that the deliveryDb (the queueName->messageId persistent map)
is sorted so when these messages are loaded back in at server startup, the
message order is preserved (as it's ordered by queueName, messageId). As far as
I can see, messageId does guantee the ordering. The AMQMessage contructor calls
store.getNewMessageId() to get the next one.
It appears that AMQMessage.requeue is unnecessary as no other methods besides
SubscriptionImpl.send() use it.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
