[
https://issues.apache.org/jira/browse/QPID-7664?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16049328#comment-16049328
]
Lorenz Quack commented on QPID-7664:
------------------------------------
{quote}For the broker it doesn't ever really make sense to set the
defaultOutcome on a source to anything other than that which the client (the
sender) sets it to. The defaultOutcome is a property of the sending side and
specifies what terminal state will be applied to a message which has been sent,
but a terminal state not sent by the receiver when the link is closed.{quote}
Sorry I mixed up sending and receiving link. The broker currently does not
modify the Source's default-outcome when the broker acts as *Receiver*.
{quote}The broker doesn't really care what the client does with a message in
this instance. It is the other direction (when a client is receiving messages
from the broker) that the client may wish to influence the behaviour (by
setting the default outcome) where the broker should inspect the value from the
client and potentially alter its behaviour and/or should set the default
outcome of the source to indicate what the broker will actually do in this
case{quote}
After an IRC conversation this is now clearer to me.
The point that was not clear to me from the spec is that the default-outcome
field is not instructional but informational. It informs the receiver of how
the sender will treat the delivery in case the delivery gets settled (sender
side) before the receiving side reached a terminal outcome.
I had (incorrectly) understood the spec to mean that the field instructs the
receiver to apply specified outcome on the receiver side if the delivery gets
settled which did not make a lot of sense.
Thanks for the clarification, Rob!
Regarding this JIRA:
The broker currently does not set the default-outcome on the Source when it
acts as sender. This is allowed by the spec.
There are two possible improvements:
* The broker sets it to whatever it does. (something like
{{modified(deliveryFailed=true)}})
* The broker modifies its behaviour to respect the default-outcome requested by
the remote peer on the attach.
> Support defaultOutcome handling
> -------------------------------
>
> Key: QPID-7664
> URL: https://issues.apache.org/jira/browse/QPID-7664
> Project: Qpid
> Issue Type: Improvement
> Components: Java Broker
> Reporter: Keith Wall
> Fix For: qpid-java-broker-7.0.0
>
>
> -The Java Broker currently does not respect the source's {{defaultOutcome}},
> despite concurring with the peer's choice.-
> -[http://docs.oasis-open.org/amqp/core/v1.0/os/amqp-core-messaging-v1.0-os.html#type-source]-
> -It currently arbitrarily decides to use a Modified\{deliveryFailed=true\} in
> some cases rather than respecting the default. Code is
> ({{org.apache.qpid.server.protocol.v1_0.ConsumerTarget_1_0.DispositionAction}}).-
> Since the JIRA was raised the code was changed and we no longer set the
> defaultOutcome on the Source for -sending- receiving links (QPID-7658).
> On receiving links we immediately apply a terminal outcome (except for
> transacted transfers were we use TransactionalState containing the terminal
> outcome).
> So if my reading of the spec is correct the default outcome would only apply
> when receiving presettled messages.
> However, this does not make a lot of sense, IMHO. For example if the sender
> requests a default outcome of Accepted and sends a presettled message that we
> do not want or can't accept we would have to apply the Accepted outcome
> anyway? On the other hand if the sender requests a default outcome of
> Rejected and sends a presettled message should we immediately drop it? Then
> why send it in the first place?
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
