[
https://issues.apache.org/jira/browse/QPID-7954?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16218631#comment-16218631
]
Lorenz Quack commented on QPID-7954:
------------------------------------
Alex pointed out to me that the above comment is not fully accurate.
On normal broker initiated detach we do not seem to discard the endpoint
immediately.
We do discard them in two cases that seem problematic:
* after sending detach due to a session end which seems problematic because the
remote peer is supposed to answer with its own detach. Furthermore, there might
still be performatives in flight.
* we remove the inputhandle in disassociateEndpoint which happens for
errant-links immediately after sending the detach. This would cause a problem
in the case where a performative is sent pipelined with the attach without
waiting for the attach response from the broker.
> [Java Broker, AMQP 1.0] Improve AMQP 1.0 detach code
> ----------------------------------------------------
>
> Key: QPID-7954
> URL: https://issues.apache.org/jira/browse/QPID-7954
> Project: Qpid
> Issue Type: Improvement
> Components: Java Broker
> Reporter: Lorenz Quack
> Fix For: Future
>
>
> Currently the AMQP detach handling code is messy.
> It could use a good refactoring and cleanup.
> Also the following issues need looking into:
> * Are we handling simultaneous detach correctly? There seems to be shared
> code between broker- and client-side detach ({{Session_1_0#detach()}}) which
> unmaps both the input and output handle.
> * We should probably have a ticker timing out clients that do not send back a
> detach after a broker side detach in a reasonable amount of time.
> * Are all state transitions handled correctly?
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
