You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@qpid.apache.org by "Robbie Gemmell (JIRA)" <ji...@apache.org> on 2019/07/22 15:04:00 UTC
[jira] [Comment Edited] (QPID-8345) [Broker-J][AMQP 1.0] Consumed messages are left in acquired state on a queue when receiver’s desired snd-settle-mode is set to settled and transactions are not used for message receiving
[ https://issues.apache.org/jira/browse/QPID-8345?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16890235#comment-16890235 ]
Robbie Gemmell edited comment on QPID-8345 at 7/22/19 3:03 PM:
---------------------------------------------------------------
Reply mostly to Rob, Alex ninja'd my comment ;)
I really don't see that possibility in what the spec says. The spec notes that default outcome field is specifically for unsettled transfers, thus ruling out the very situation discussed. My reading is that its for use when the unsettled delivery is being settled without a state becoming known from the receiver side, as noted including when the source itself is going away, e.g because the connection is severed or such like.
It makes no sense to me from reading it that it could be possible to apply a default outcome, "for transfers that have not reached a terminal state at the receiver", in a case where they never can reach a terminal state at the receiver, as everything was done before it the message was ever sent.
The examples usages given are released and rejected, which would be especially stupid for a pre-settled transfers, but using those examples is actually reasonable since its noted immiadately that the field applies only to unsettled transfers.
was (Author: gemmellr):
I really don't see that possibility in what the spec says. The spec notes that default outcome field is specifically for ** unsettled transfers, thus ruling out the very situation discussed. My reading is that its for use when the unsettled delivery is being settled without a state becoming known from the receiver side, as noted including when the source itself is going away, e.g because the connection is severed or such like.
It makes no sense to me from reading it that it could be possible to apply a default outcome, "for transfers that have not reached a terminal state at the receiver", in a case where they never can reach a terminal state at the receiver, as everything was done before it the message was ever sent.
The examples usages given are released and rejected, which would be especially stupid for a pre-settled transfers, but using those examples is actually reasonable since its noted immiadately that the field applies only to unsettled transfers.
> [Broker-J][AMQP 1.0] Consumed messages are left in acquired state on a queue when receiver’s desired snd-settle-mode is set to settled and transactions are not used for message receiving
> ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
>
> Key: QPID-8345
> URL: https://issues.apache.org/jira/browse/QPID-8345
> Project: Qpid
> Issue Type: Bug
> Components: Broker-J
> Affects Versions: qpid-java-broker-7.0.0, qpid-java-broker-7.0.1, qpid-java-broker-7.1.0, qpid-java-broker-7.0.4, qpid-java-broker-7.0.5, qpid-java-broker-7.0.6, qpid-java-broker-7.0.7, qpid-java-broker-7.1.1, qpid-java-broker-7.1.2, qpid-java-broker-7.0.8, qpid-java-broker-7.1.3, qpid-java-broker-7.1.4
> Reporter: Alex Rudyy
> Priority: Major
> Fix For: qpid-java-broker-7.1.5
>
>
> When receiving link desired {{snd-settle-mode}} is set to {{settled}} and transactions are not used for message receiving, the broker sending link sends the messages pre-settled.
> However, the consumed messages are left in acquired state on the queue after sending them to consumer. Such messages stack in {{acquired}} state until broker is restarted. After the restart, the persistent message became available for consumption again.
> The broker currently does not apply {{default-outcome}} set on receiving link (indicating the outcome to be used for transfers that have not reached a terminal state at the
> receiver when the transfer is settled [see section 3.5.3 Source]).
> Based on value of {{default-outcome}} set on consumer link source, the broker should apply the following:
> * {{accepted}} or {{null}}; remove message from the queue
> * {{rejected}}, {{released}}, {{modified}}; release message
> * any other outcome; close link with an error {{not-implemented}}
> * not valid outcome (for example, {{received}}); close link with an error {{invalid-field}}
--
This message was sent by Atlassian JIRA
(v7.6.14#76016)
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@qpid.apache.org
For additional commands, e-mail: dev-help@qpid.apache.org