[
https://issues.apache.org/jira/browse/DISPATCH-1020?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16501882#comment-16501882
]
Gordon Sim commented on DISPATCH-1020:
--------------------------------------
One complication is the recent change to share a session between all link
routes. The default terminus-expiry-policy in both source and target is
session-end, meaning I think that the correct behaviour on receiving the detach
with closed=false for a link in which an explicit terminus-expiry-policy was
not requested, would be to keep the terminus state until the shared session
ended. That probably isn't what is usually wanted.
One option might be to explicitly set the terminus-expiry-policy before
propagating it to the broker. Not sure if that is any better than just issuing
the closed=true in the case that the terminus does not survive connection loss.
> Detach expiring links with closed=true when peer connectivity lost
> ------------------------------------------------------------------
>
> Key: DISPATCH-1020
> URL: https://issues.apache.org/jira/browse/DISPATCH-1020
> Project: Qpid Dispatch
> Issue Type: Improvement
> Reporter: Keith Wall
> Assignee: Ganesh Murthy
> Priority: Major
> Fix For: 1.2.0
>
>
> Currently, Dispatch responds to the loss of an underlying connection to a
> peer by detaching the links established over that connection in the following
> way.
> {noformat}
> @detach(22) [handle=0, closed=false, error=@error(29)
> [condition=:"qd:routed-link-lost", description="Connectivity to the peer
> container was lost”]]
> {noformat}
> As is makes no sense for link defined to expire to attached again, it would
> be an improvement to the dispatch's behaviour if those links were detached
> with {{closed=true}}. This would aid the timely clean-up of resources
> elsewhere in the AMQP network.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
