You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@qpid.apache.org by "Chuck Rolke (JIRA)" <ji...@apache.org> on 2016/11/14 20:35:59 UTC
[jira] [Commented] (DISPATCH-562) Router does not forward
dispositions when client detach/close is in same frame
[ https://issues.apache.org/jira/browse/DISPATCH-562?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15664938#comment-15664938 ]
Chuck Rolke commented on DISPATCH-562:
--------------------------------------
The original issue misidentifies the routing scenario as message routing when it is actually link routing. Note that the tool shows the Attach frames having source and target = null. Digging deeper the actual endpoints were not null. Somewhere along the way Wireshark changed how it encodes AMQP frames in pdml. I've fixed this in my tool [1]
A corrected trace is:
{noformat}
◊ ◊◊ 5.245176 Frame 39 [::1]:40896 -> [::1]:9001 -> init AMQP (0): (1.0.0), open [0], begin [0,null], attach [0,0] sender link_0 (source: null, target: endpoint_1)
◊ ◊◊ 5.245340 Frame 41 [::1]:40896 <- [::1]:9001 <- init AMQP (0): (1.0.0)
◊ ◊◊ 5.245406 Frame 42 [::1]:40896 <- [::1]:9001 <- open [0], begin [0,0]
◊ ◊◊ 5.245409 Frame 43 [::1]:39572 -> [::1]:9002 -> init AMQP (0): (1.0.0), open [0], begin [0,null], attach [0,0] receiver link_1 (source: endpoint_1, target: null), flow [0,0] (0,10)
◊ ◊◊ 5.245476 Frame 45 [::1]:48300 -> [::1]:5672 -> begin [0,null], attach [0,0] sender link_0 (source: null, target: endpoint_1)
◊ ◊◊ 5.246329 Frame 48 [::1]:48300 <- [::1]:5672 <- begin [0,0], attach [0,0] receiver link_0 (source: null, target: endpoint_1), flow [0,0] (0,500)
◊ ◊◊ 5.246389 Frame 50 [::1]:39572 <- [::1]:9002 <- init AMQP (0): (1.0.0), open [0], begin [0,0]
◊ ◊◊ 5.246464 Frame 52 [::1]:48298 -> [::1]:5672 -> begin [0,null], attach [0,0] receiver link_1 (source: endpoint_1, target: null), flow [0,0] (0,10)
◊ ◊◊ 5.246581 Frame 54 [::1]:40896 <- [::1]:9001 <- attach [0,0] receiver link_0 (source: null, target: endpoint_1), flow [0,0] (0,500)
◊ ◊◊ 5.246878 Frame 56 [::1]:40896 -> [::1]:9001 -> transfer [0,0] (0..4)
◊ ◊◊ 5.247085 Frame 58 [::1]:48298 <- [::1]:5672 <- begin [0,0], attach [0,0] sender link_1 (source: endpoint_1, target: null)
◊ ◊◊ 5.247207 Frame 59 [::1]:39572 <- [::1]:9002 <- attach [0,0] sender link_1 (source: endpoint_1, target: null)
◊ ◊◊ 5.247236 Frame 61 [::1]:48300 -> [::1]:5672 -> transfer [0,0] (0..4)
◊ ◊◊ 5.247481 Frame 63 [::1]:48300 <- [::1]:5672 <- flow [0,0] (5,500), disposition [0] (receiver 0-4)
◊ ◊◊ 5.247571 Frame 64 [::1]:48298 <- [::1]:5672 <- transfer [0,0] (0..4)
◊ ◊◊ 5.247575 Frame 65 [::1]:40896 <- [::1]:9001 <- flow [0,0] (5,500), disposition [0] (receiver 0-4)
◊ ◊◊ 5.247648 Frame 67 [::1]:40896 -> [::1]:9001 -> close [0]
◊ ◊◊ 5.247702 Frame 68 [::1]:40896 <- [::1]:9001 <- close [0]
◊ ◊◊ 5.250888 Frame 72 [::1]:39572 <- [::1]:9002 <- transfer [0,0] (0..4)
◊ ◊◊ 5.251012 Frame 74 [::1]:48300 -> [::1]:5672 -> detach [0,0]
◊ ◊◊ 5.251075 Frame 75 [::1]:48300 <- [::1]:5672 <- detach [0,0]
◊ ◊◊ 5.251161 Frame 76 [::1]:39572 -> [::1]:9002 -> disposition [0] (receiver 0-4), detach [0,0], close [0]
◊ ◊◊ 5.251231 Frame 77 [::1]:39572 <- [::1]:9002 <- close [0]
◊ ◊◊ 5.251235 Frame 78 [::1]:48298 -> [::1]:5672 -> detach [0,0]
◊ ◊◊ 5.251540 Frame 82 [::1]:48298 <- [::1]:5672 <- disposition [0] (sender 0-0), disposition [0] (sender 1-1), disposition [0] (sender 2-2), disposition [0] (sender 3-3), disposition [0] (sender 4-4), detach [0,0]
{noformat}
The endpoint index:
{noformat}
endpoint_0 - null
endpoint_1 - jms.queue.qpid-interop.amqp_types_test.binary.ProtonCpp.ProtonCpp
endpoint_2 - jms.queue.qpid-interop.amqp_types_test.boolean.ProtonCpp.ProtonCpp
....
{noformat}
[1] https://github.com/ChugR/Adverb/commit/06c2cfc8930f80cddfabae2abfd74fae152f7b77
> Router does not forward dispositions when client detach/close is in same frame
> ------------------------------------------------------------------------------
>
> Key: DISPATCH-562
> URL: https://issues.apache.org/jira/browse/DISPATCH-562
> Project: Qpid Dispatch
> Issue Type: Bug
> Components: Container
> Affects Versions: 0.8.0
> Environment: qpid-interop-test
> $ amqp_types_test.py --sender localhost:9001 --receiver localhost:9002
> Reporter: Chuck Rolke
>
> In this test there are two clients, two routers, and one broker.
> {noformat}
> [Sender] --> [Node 1/9001] --> [Broker] --> [Node 2/9002] --> [Receiver]
> {noformat}
> Messages are accepted successfully but sometimes they get stuck in the broker. This problem is illustrated by this AMQP stream:
> {noformat}
> ◊ ◊◊ 5.245176 Frame 39 [::1]:40896 -> [::1]:9001 -> init AMQP (0): (1.0.0), open [0], begin [0,null], attach [0,0] sender link_0 (source: null, target: null)
> ◊ ◊◊ 5.245340 Frame 41 [::1]:40896 <- [::1]:9001 <- init AMQP (0): (1.0.0)
> ◊ ◊◊ 5.245406 Frame 42 [::1]:40896 <- [::1]:9001 <- open [0], begin [0,0]
> ◊ ◊◊ 5.245409 Frame 43 [::1]:39572 -> [::1]:9002 -> init AMQP (0): (1.0.0), open [0], begin [0,null], attach [0,0] receiver link_1 (source: null, target: null), flow [0,0] (0,10)
> ◊ ◊◊ 5.245476 Frame 45 [::1]:48300 -> [::1]:5672 -> begin [0,null], attach [0,0] sender link_0 (source: null, target: null)
> ◊ ◊◊ 5.246329 Frame 48 [::1]:48300 <- [::1]:5672 <- begin [0,0], attach [0,0] receiver link_0 (source: null, target: null), flow [0,0] (0,500)
> ◊ ◊◊ 5.246389 Frame 50 [::1]:39572 <- [::1]:9002 <- init AMQP (0): (1.0.0), open [0], begin [0,0]
> ◊ ◊◊ 5.246464 Frame 52 [::1]:48298 -> [::1]:5672 -> begin [0,null], attach [0,0] receiver link_1 (source: null, target: null), flow [0,0] (0,10)
> ◊ ◊◊ 5.246581 Frame 54 [::1]:40896 <- [::1]:9001 <- attach [0,0] receiver link_0 (source: null, target: null), flow [0,0] (0,500)
> ◊ ◊◊ 5.246878 Frame 56 [::1]:40896 -> [::1]:9001 -> transfer [0,0] (0..4)
> ◊ ◊◊ 5.247085 Frame 58 [::1]:48298 <- [::1]:5672 <- begin [0,0], attach [0,0] sender link_1 (source: null, target: null)
> ◊ ◊◊ 5.247207 Frame 59 [::1]:39572 <- [::1]:9002 <- attach [0,0] sender link_1 (source: null, target: null)
> ◊ ◊◊ 5.247236 Frame 61 [::1]:48300 -> [::1]:5672 -> transfer [0,0] (0..4)
> ◊ ◊◊ 5.247481 Frame 63 [::1]:48300 <- [::1]:5672 <- flow [0,0] (5,500), disposition [0] (receiver 0-4)
> ◊ ◊◊ 5.247571 Frame 64 [::1]:48298 <- [::1]:5672 <- transfer [0,0] (0..4)
> ◊ ◊◊ 5.247575 Frame 65 [::1]:40896 <- [::1]:9001 <- flow [0,0] (5,500), disposition [0] (receiver 0-4)
> ◊ ◊◊ 5.247648 Frame 67 [::1]:40896 -> [::1]:9001 -> close [0]
> ◊ ◊◊ 5.247702 Frame 68 [::1]:40896 <- [::1]:9001 <- close [0]
> ◊ ◊◊ 5.250888 Frame 72 [::1]:39572 <- [::1]:9002 <- transfer [0,0] (0..4)
> ◊ ◊◊ 5.251012 Frame 74 [::1]:48300 -> [::1]:5672 -> detach [0,0]
> ◊ ◊◊ 5.251075 Frame 75 [::1]:48300 <- [::1]:5672 <- detach [0,0]
> ◊ ◊◊ 5.251161 Frame 76 [::1]:39572 -> [::1]:9002 -> disposition [0] (receiver 0-4), detach [0,0], close [0]
> ◊ ◊◊ 5.251231 Frame 77 [::1]:39572 <- [::1]:9002 <- close [0]
> ◊ ◊◊ 5.251235 Frame 78 [::1]:48298 -> [::1]:5672 -> detach [0,0]
> ◊ ◊◊ 5.251540 Frame 82 [::1]:48298 <- [::1]:5672 <- disposition [0] (sender 0-0), disposition [0] (sender 1-1), disposition [0] (sender 2-2), disposition [0] (sender 3-3), disposition [0] (sender 4-4), detach [0,0]
> {noformat}
> This trace is from a message routing scenario with:
> * Sender client (port 40896) connects to routerA (port 9001)
> * Receiver client (port 39572) connects to routerB (port 9002)
> * RouterA (port 48300) connects to Qpidd broker (port 5672)
> * RouterB (port 48298) connects to Qpidd broker (port 5672)
> Note that the router-broker connections are long lived and don't start or stop in this trace.
> * Frames 39..68 include link setup and the complete transfer of frames from the sender.
> * Frame 72 has the transfer of 5 messages to the receiver client.
> * Frames 74..75 is RouterA detaching the clients sender link to the broker
> * Frame 76 is the receiver sending accepted dispositions for all five frames to routerB.
> Note that this frame also has the link detach and connection close.
> * Frame 77 is routerB closing the connection to the receiver client.
> * Frame 78 is routerB detaching the receiver's link to the broker.
> * Frame 86 is the broker sending back five dispositions with Settled=true but not Accepted. The messages remain in the broker. The broker also closes the link.
> The issue is that routerB did not forward the receiver client's dispositions in Frame 76 to the broker but just detached the link.
> {noformat}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@qpid.apache.org
For additional commands, e-mail: dev-help@qpid.apache.org