[
https://issues.apache.org/jira/browse/DISPATCH-506?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15484087#comment-15484087
]
Robbie Gemmell commented on DISPATCH-506:
-----------------------------------------
I'm not entirely against the idea of a link detach with an error, as I say I'm
not sure and I can see arguments both ways. I'm really only truly interested
with what the detach 'closed' value is if it does send one.
A direct equivalence to the unrouted case is indeed not possible without the
router dropping the connection to the end server, which it cant really do
unless that particular clients link(s) happen to be the only one(s) using that
connection to the server (or it felt it was ok to pretend to all the other
clients that the server went away and dropped their router connections too :P)
That said, I do think ending the session alone is essentially logically
equivalent, since the session is either there or not and the servers behaviour
relating to the links should effectively be the same regardless how that
transition occurs (TCP close without any AMQP teardown first, or AMQP
connection close without explicitly ending the session, or an AMQP session end).
I'd possibly go for a custom error if sending one, not-found could be argued
but I think thats probably not how most would normally think of it being used,
and detach-forced seems debatable since it describes an operator intervening.
> Detach with no "error" sent by router on client TCP connection dropped
> ----------------------------------------------------------------------
>
> Key: DISPATCH-506
> URL: https://issues.apache.org/jira/browse/DISPATCH-506
> Project: Qpid Dispatch
> Issue Type: Bug
> Affects Versions: 0.6.1
> Reporter: Paolo Patierno
>
> Hi,
> I got the following scenario.
> A router with a link routing configured on address "my_queue".
> A broker hosting "my_queue".
> A Python receiver connected to that queue through the link routing provided
> by the router.
> If I kill the receiver, so the TCP connection between client and router is
> dropped, the client (of course) doesn't send a detach to the broker for the
> link but the router is in charge to do that.
> What happens is that this detach message doesn't contain an "error" field in
> order to distinguish between a clean detach from the client or a detach sent
> by router due to client "brute" disconnection.
> Following the trace I have :
> [0x16e07f0]: <- EOS
> [0x16e07f0]: -> EOS
> Closed 127.0.0.1:42308
> Unexpected poll events: 0020 on 127.0.0.1:42308
> [0x16cf470]:0 -> @detach(22) [handle=0, closed=true]
> [0x16cf470]:0 <- @detach(22) [handle=0, closed=true]
> [0x16cf470]:0 -> @end(23) []
> [0x16cf470]:0 <- @end(23) []
> I think that it could make sense that router sends a detach with "error" when
> something like that happens.
> The current is a bug or a behavior ?
> Thanks,
> Paolo.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
