[
https://issues.apache.org/jira/browse/DISPATCH-506?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15483879#comment-15483879
]
Paolo Patierno edited comment on DISPATCH-506 at 9/12/16 11:43 AM:
-------------------------------------------------------------------
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.
I have to admit that the usage of "closed" flag is not so clear here, but
having an "error" with information about a "client TCP connection lost" could
be great and clear for the server.
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 ?
was (Author: ppatierno):
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.
I have to admit that the usage of "close" flag is not so clear here, but having
an "error" with information about a "client TCP connection lost" could be great
and clear for the server.
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 ?
> 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: dev-unsubscr...@qpid.apache.org
For additional commands, e-mail: dev-h...@qpid.apache.org
