[
https://issues.apache.org/jira/browse/PROTON-2108?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17046441#comment-17046441
]
Gordon Sim commented on PROTON-2108:
------------------------------------
Re "There is potentially possibility though that a peer could also e.g detach
the link with an error rather than accept and silently swallow the messages
though". If accepted is the only valid outcome when outcomes and
default-outcome are not specified then surely detaching the link with an error
would imply accepted since the default outcome must be assumed to be a valid
outcome and only accepted is valid. i.e. detaching the link with an error would
not avoid silently swallowing the messages.
Re "a definition along the lines that [~gsim] proposed above _"any of the
outcomes are valid"_ would mean that it is implicitly saying that it will
accept the new outcome "send_me_helium_filled_elephants" that I have just
invented", I think it would be intuitive and obvious to assume that no outcomes
implies that all those concrete outcomes defined by the messaging layer are
valid. I.e. that to use extensions you would need to indicate support for them,
or to exclude certain standard outcomes you would likewise need to list those
you don't support. That is of course not explicitly stated, but neither is it
explicitly stated that accepted is the ONLY valid outcome in such cases (only
that it MUST be supported). It would have been clearer and less ambiguous if
the text explicitly stated e.g. 'if the default-outcome is not set, and no
outcomes are provided, then the
[accepted|http://docs.oasis-open.org/amqp/core/v1.0/os/amqp-core-messaging-v1.0-os.html#type-accepted]
outcome MUST be supported by the source and this is the ONLY valid outcome',
which given the definition of accepted means there is no possibility to
indicate failure to process, or even to distinguish which deliveries were
processed or not at the point the connection was lost. So to me the mistake is
not leaving outcomes open, but in leaving the apparent intent implied rather
than explicitly stated where that apparent intent is far from intuitive in its
implications.
However I doubt anyone will be helped by clarification in a spec erratum at
this point.
> supported source outcomes not set
> ---------------------------------
>
> Key: PROTON-2108
> URL: https://issues.apache.org/jira/browse/PROTON-2108
> Project: Qpid Proton
> Issue Type: Bug
> Affects Versions: proton-c-0.29.0
> Reporter: Robbie Gemmell
> Priority: Critical
>
> From looking at some recent traces, it appears that the bindings (at least
> for python, but probably others) do no set the outcomes (or default-outcome)
> field on its source terminus, although they do use/support all the outcomes.
> To a peer that actually inspects the outcomes to influence behaviour this
> strictly means only Accepted is supported, which can lead to issues (e.g it
> might accept a message then drop it, rather than release/modify/reject it,
> under cases it couldn't be processed).
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
