[
https://issues.apache.org/jira/browse/QPID-7962?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16200125#comment-16200125
]
Alex Rudyy commented on QPID-7962:
----------------------------------
I investigated the issue a bit further. It happens when available for delivery
message is stolen by the {{clearQueue}} operation when
{{AbstractQueue#attemptDelivery}} is called from
{{AbstractQueue#deliverSingleMessage}}. If message is stolen
{{AbstractQueue#attemptDelivery}} returns {{MessageContainer}} where
{{MessageInstance}} is {{null}} but flag {{hasNoAvailableMessages}} is set to
{{false}} (It is a reference to
{{org.apache.qpid.server.queue.AbstractQueue#HAS_MESSAGES}}). If consumer
acquires and queue has more messages, the current implementation of
{{AbstractQueue#deliverSingleMessage}} tries to notify other queue consumers
(excluding the current one). As result, the current consumer remains in
{{INTERESTED}} state and it is not added into
{{AbstractAMQPSession#_consumersWithPendingWork}}. In cases when there is no
other consumers and no publishing activities, the current consumer might not be
notified that queue is empty( until new message arrives, new consumer is
attached). Thus, when {{clearQueue}} finishes the message removal, the
consumer is not get notified about queue being empty and it cannot send the
flow back (call to {{QueueConsumer#queueEmpty}} is currently required to send
flow back when consumer is draining).
Also, I am wondering whether the same issue can happen for multiple consumers
when draining consumer cannot acquire the message (for example, due to
non-matching filter) but the competing consumer can consume it and if the
message is the last one, I do not see how draining consumer can be notified
about queue being empty in order to send flow.
The naive approach to fix the issue would be to always call {{notifyWork}} on
the consumer when {{AbstractQueue#HAS_MESSAGES}} is returned by
{{AbstractQueue#attemptDelivery}} but that might screw fairness and might cause
unnecessary pending work cycles.
> [Java Broker][AMQP 1.0] In some circumstances Broker fails to send Flow back
> when Flow with drain flag set is received from client
> ----------------------------------------------------------------------------------------------------------------------------------
>
> Key: QPID-7962
> URL: https://issues.apache.org/jira/browse/QPID-7962
> Project: Qpid
> Issue Type: Bug
> Components: Java Broker
> Affects Versions: qpid-java-broker-7.0.0
> Reporter: Alex Rudyy
> Priority: Minor
> Fix For: qpid-java-broker-7.0.0
>
> Attachments:
> TEST-org.apache.qpid.server.queue.LiveQueueOperationsTest.testClearQueueOperationWithActiveConsumerDlqAll.txt
>
>
> Occasionally when clear queue operation is invoked from management and
> {{Flow}} with {{drain}} flag is received from client concurrently, the
> {{Broker}} might not send {{Flow}} back after clearing the queue.
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org
For additional commands, e-mail: dev-h...@qpid.apache.org
