On 15/05/18 22:10, Alan Conway wrote:
Having trouble loggingn into reviewboard
I'm not sure if this is correct. If the link is not PN_LOCAL_CLOSED, then
the application is well within its rights to close() it.
I don't understand your point. This has no effect on what the
application can do with any link objects it has. It only affects the
link object that gets associated with a PN_LINK_REMOTE_OPEN event.
If we have re-used
it for another link that could close the wrong link.
Closing the link operates on a pn_link_t object the application created
or got from an initial event. Where the peer sent an attach after a
detach, this change causes the link object associated with the
PN_LINK_REMOTE_OPEN event for the second attach to be a new link object,
not the link object associated with the preceding detach, which is not
in a usable state.
This would be the 3rd time we've changed this particular line of code in
the last few months,
I don't think so, git blame on master shows:
fd26ec66 proton-c/src/transport/transport.c (Gordon Sim
2015-04-17 11:41:10 +0100 1268)
each time we find some new situation that fails. I'm
inclined to think we should never re-use a "dead" link, and instead find
out why proton is leaving these "dead" links lying around and fix that.
This change doesn't involve re-using a dead link. If there is a link
with the same name that has been closed or detached by the peer it skips
that link and therefore assumes a new link.
The change from the current code is that it *doesn't* try to reuse the
'dead' link if the peer has closed (or detached) it, regardless of the
local status. As the function ins only used for handling an incoming
attach from the peer that seems correct to me.
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
