[
https://issues.apache.org/jira/browse/DISPATCH-506?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15483922#comment-15483922
]
Robbie Gemmell commented on DISPATCH-506:
-----------------------------------------
{quote}
If the router weren't in the middle, the other server would see a dropped TCP
connection from the client.
In this case the connection level is handled by the router (from it to the
server) and the server should have a way to understand that the client dropped
the connection in a not clean way.
{quote}
Yes, as far as the broker/server is concerned the router is the client, and the
router presumably didnt drop the connection as other things are likely using
the same connection?. Arguably the closest the router could get to achieving
the same server side effect without dropping the connection would be to end the
session only, without detaching the link at all, giving the same logical
'session has gone away but client didn't explicitly do anything to the links'
overall behaviour as far as the server is concerned. Whether it was 'clean' or
not and whether the connection closes/drops shouldnt really matter at that
point, neither should particularly affect the behaviour at the server.
The router detaching(/closing) the link to the end broker/server with an error
would arguably still be quite different from what the actual client did to the
router.
{quote}
You said "there are certainly cases that closing the link if the client
dissapears is the wrong thing to do", so you mean that the router should not
send the "detach" on behalf of client. What is a case where it could be useful ?
{quote}
Essentially. At the very least it shouldnt set closed=true, but arguably as
outlined above it possibly shouldnt do anything except end the session.
> 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]
