[ 
https://issues.apache.org/jira/browse/DISPATCH-506?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15484089#comment-15484089
 ] 

Paolo Patierno commented on DISPATCH-506:
-----------------------------------------

Saying that the router is the client for the broker/server could be true on 
using auto-link but it's not completely true for link routing with a virtual 
connection established between the real client and the broker/server through 
the router.

My perception (but you guys have more experience than me on that) is that 
customers (in their application) rely much more on the link concept than on 
connection and session. I saw a lot of applications opening connection/session 
just because they have to (it's how AMQP works) but then they rely always on 
"patterns" links related inside that ... of course this consideration (due to 
my experience) could be totally wrong ;)

> 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]

Reply via email to