Github user gemmellr commented on the issue:
https://github.com/apache/qpid-proton/pull/142
> Thanks - I didn't know about stolen. I think we could implement what the
spec says on the server side - close the old link/handle with "stolen" and
create a new link under the new handle.
In the same place its doing it now, or for the whole connection? (Still
leaving other connections as something for the using server, e.g dispatch, to
handle on its own).
Its worth saying that it doesnt currently check the handle is appropriate
as it chokes on the name first. It'd need to check the handles more fully too,
e.g two attaches with the same name and the same remote handle would still be
an session:handle-in-use error.
> That would fix the crash, which was because of multiple handles to the
same link object - we'd have a seprate link object for each handle, all but one
of which are closed with "stolen".
One further annoyance is how to inform the stuff already using the link
that this all happened.
As I mentioned elsewhere before, this also starts getting into issues with
limits checking e.g maxHandles (as it may still be 'in use' until the engine is
processed later).
>I think on the client side its always an error to try to attach if you
already have a link with same name an a handle. After disconnect all handles
are cleared, so it is OK an error to re-attach during reconnect. I want to fix
the client to refuse to create a link at all in this case. That would prevent
this happening on the wire and give more immediate feedback to code that is
mistakenly trying to double-attach.
I think thats fair personally, always have.
> The fix is not trivial due to proton's batch-processing madness or I'd
have done it first.
I feel your pain from previously looking at similar stuff :)
---
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
