[
https://issues.apache.org/jira/browse/QPID-8082?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Alex Rudyy updated QPID-8082:
-----------------------------
Description:
The link endpoint is destroyed when the link is detached with an error. Such
link cannot be reattached. Thus, any unsettled deliveries can be safely cleared
on the link endpoint.
Clearing of unsettled deliveries should ensure that any undesired disposition
will not be sent after closing the link as the state carried via such
disposition should be ignored on peer as per section {{2.7.6 Disposition}} of
AMQP specification
{quote}
The disposition performative MAY refer to deliveries on links that are no
longer attached. As long as the links have not been closed or detached with an
error then the deliveries are still “live” and the updated state MUST be
applied.
{quote}
At the moment, the disposition may arrive from detached errant standard
receiving link endpoint( after its close due to error), when transaction for
the delivery is discharged (The delivery is settled with null state when
transaction is rolled back). It does not look right to me to send such
disposition, as it does not change anything on the peer
was:
The link endpoint is destroyed when the link is detached with an error. Such
link cannot be reattached. Thus, any unsettled deliveries can be safely cleared
on the link endpoint.
Clearing of unsettled deliveries should ensure that any undesired disposition
will not be sent after closing the link as the state carried via such
disposition should be ignored on peer as per section {{2.7.6 Disposition}} of
AMQP specification
{quote}
The disposition performative MAY refer to deliveries on links that are no
longer attached.
As long as the links have not been closed or detached with an error then the
deliveries are still “live” and the updated state MUST be applied.
{quote}
At the moment, the disposition may arrive from errant standard receiving link
endpoint after its close due to error, when transaction for the delivery is
discharged (The delivery is settled with null state when transaction is rolled
back). It does not look right to me to send such disposition, as it does not
change anything on the peer
> [Broker-J][AMQP 1.0] Clear unsettled map when receiving link is detached due
> to an error
> ----------------------------------------------------------------------------------------
>
> Key: QPID-8082
> URL: https://issues.apache.org/jira/browse/QPID-8082
> Project: Qpid
> Issue Type: Bug
> Components: Broker-J
> Affects Versions: qpid-java-broker-7.0.0
> Reporter: Alex Rudyy
> Priority: Major
> Fix For: qpid-java-broker-7.0.1
>
> Attachments:
> 0001-Broker-J-AMQP-1.0-Clear-unsettled-map-when-receiving.patch
>
>
> The link endpoint is destroyed when the link is detached with an error. Such
> link cannot be reattached. Thus, any unsettled deliveries can be safely
> cleared on the link endpoint.
> Clearing of unsettled deliveries should ensure that any undesired disposition
> will not be sent after closing the link as the state carried via such
> disposition should be ignored on peer as per section {{2.7.6 Disposition}} of
> AMQP specification
> {quote}
> The disposition performative MAY refer to deliveries on links that are no
> longer attached. As long as the links have not been closed or detached with
> an error then the deliveries are still “live” and the updated state MUST be
> applied.
> {quote}
> At the moment, the disposition may arrive from detached errant standard
> receiving link endpoint( after its close due to error), when transaction for
> the delivery is discharged (The delivery is settled with null state when
> transaction is rolled back). It does not look right to me to send such
> disposition, as it does not change anything on the peer
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org
For additional commands, e-mail: dev-h...@qpid.apache.org
