Marco Geri created QPID-8599:
--------------------------------
Summary: [Broker-J] Client receives `Delivery-tag '%s' is used by
another unsettled delivery.` for already settled tag
Key: QPID-8599
URL: https://issues.apache.org/jira/browse/QPID-8599
Project: Qpid
Issue Type: Bug
Components: Broker-J
Affects Versions: qpid-java-broker-8.0.6
Reporter: Marco Geri
Using ProtonJ2 client sender with Delivery Mode AT_LEAST_ONCE, i.e.:
* Sender Settle Mode: Unsettled
* Receiver Settle Mode: First
* Pooled tag generator: when receiving a remote settle, a tag is pooled for
reuse in a next delivery
* Auto settle enabled: when receiving a remote settle, it settles the delivery
During some sending peaks, sometimes the client receives the server error:
_Delivery-tag 'X' is used by another unsettled delivery._
I don't know in detail how it works (sorry if I'm wrong), but with some
debugging, it seems to happen something similar to this example:
* the client sends two delivery messages with tags "10" and "11"
* the client receives the remote settle and puts tags "10" and "11" to
reusable pooled tags
* meanwhile, a new message is ready to be delivered and the client sends in
this sequence the following messages: settle tag "10", settle tag "11", a new
delivery message with tag "10" (reusing the "10" tag)
When the BrokerJ receives this sequence it seems it processes all the messages
on the on "receive complete" event, with the {{processPendingDispositions.}}
But before doing it, it seems that it checks for an already used tag on a
single receive, although if there is a "client settle message" for the tag
"10" in the pending dispositions, it finds the tag "10" in the unsettled set
collection (ignoring that it will be removed from it in the "process pending
disposition"), giving the "Delivery `10` tag is used ..." error.
I'm not an AMQP and BrokerJ expert and I don't know if I'm missing something
and this is expected behavior and if the problem should be resolved on the
client side.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
