[jira] [Commented] (THRIFT-4451) Rust client fails to communicate with multiplexed perl/c_glib servers
[
https://issues.apache.org/jira/browse/THRIFT-4451?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16681366#comment-16681366
]
Allen George commented on THRIFT-4451:
--
!Screen Shot 2018-11-09 at 07.03.39.png!
Here's a representative sample of what I'm seeing. Specifically, after the call
to the second-test server is sent and the server responds with an {{ACK}}, the
client immediately sends out a {{FIN}}. Now, once the server sends its response
the client thinks the connection is dead, and so of course nothing is read.
AFAICT, I'm not invoking {{shutdown()}} explicitly, neither is {{Drop}} on the
{{TcpStream}} getting called.
> Rust client fails to communicate with multiplexed perl/c_glib servers
> -
>
> Key: THRIFT-4451
> URL: https://issues.apache.org/jira/browse/THRIFT-4451
> Project: Thrift
> Issue Type: Bug
> Components: Rust - Library
>Reporter: Allen George
>Assignee: Allen George
>Priority: Major
> Attachments: Screen Shot 2018-11-09 at 07.03.39.png
>
>
> As stated in description. Minimal case is to comment out everything in the
> Rust {{test_client}} leaving only the {{SecondService}} call behind.
> From what I can tell the Rust socket isn't getting *any* bytes at all for the
> response (i.e. it can't even get the first 4 bytes of the message header).
> There is a {{flush()}} call on the remote side - so that's puzzling.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (THRIFT-4451) Rust client fails to communicate with multiplexed perl/c_glib servers
[
https://issues.apache.org/jira/browse/THRIFT-4451?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16679271#comment-16679271
]
Allen George commented on THRIFT-4451:
--
Somehow the client is shutting down the connection before it receives the
replies. I'm seeing {FIN}s from the client-> server. I'm sure it's a lifetime
issue...
> Rust client fails to communicate with multiplexed perl/c_glib servers
> -
>
> Key: THRIFT-4451
> URL: https://issues.apache.org/jira/browse/THRIFT-4451
> Project: Thrift
> Issue Type: Bug
> Components: Rust - Library
>Reporter: Allen George
>Assignee: Allen George
>Priority: Major
>
> As stated in description. Minimal case is to comment out everything in the
> Rust {{test_client}} leaving only the {{SecondService}} call behind.
> From what I can tell the Rust socket isn't getting *any* bytes at all for the
> response (i.e. it can't even get the first 4 bytes of the message header).
> There is a {{flush()}} call on the remote side - so that's puzzling.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (THRIFT-4451) Rust client fails to communicate with multiplexed perl/c_glib servers
[
https://issues.apache.org/jira/browse/THRIFT-4451?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16674610#comment-16674610
]
Allen George commented on THRIFT-4451:
--
Noticing the same problem with cpp servers as well.
> Rust client fails to communicate with multiplexed perl/c_glib servers
> -
>
> Key: THRIFT-4451
> URL: https://issues.apache.org/jira/browse/THRIFT-4451
> Project: Thrift
> Issue Type: Bug
> Components: Rust - Library
>Reporter: Allen George
>Assignee: Allen George
>Priority: Major
>
> As stated in description. Minimal case is to comment out everything in the
> Rust {{test_client}} leaving only the {{SecondService}} call behind.
> From what I can tell the Rust socket isn't getting *any* bytes at all for the
> response (i.e. it can't even get the first 4 bytes of the message header).
> There is a {{flush()}} call on the remote side - so that's puzzling.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (THRIFT-4451) Rust client fails to communicate with multiplexed perl/c_glib servers
[
https://issues.apache.org/jira/browse/THRIFT-4451?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16407862#comment-16407862
]
Allen George commented on THRIFT-4451:
--
Weirdly enough, here's the sequence of back and forth. The perl server is
listening on 45773
{noformat}
< REQUEST
12:48:59.775728 IP (tos 0x0, ttl 64, id 57597, offset 0, flags [DF], proto TCP
(6), length 113)
[6/1830]
127.0.0.1.52408 > 127.0.0.1.45773: Flags [P.], cksum 0xfe65 (incorrect ->
0xa11f), seq 1:62, ack 1, win 342, options [nop,nop,TS val 6743292 ecr
6743292], length 61
E..q..@.@.[.N...zu.V.e.
.f...f..SecondService:secondtestString...test_string.
WHAT IS THIS?!
12:48:59.775740 IP (tos 0x0, ttl 64, id 14716, offset 0, flags [DF], proto TCP
(6), length 52)
127.0.0.1.45773 > 127.0.0.1.52408: Flags [.], cksum 0xfe28 (incorrect ->
0x81e0), seq 1, ack 62, win 342, options [nop,nop,TS val 6743292 ecr 6743292],
length 0
E..49|@.@..Fzu..N..E...V.(.
.f...f..
WHAT IS THIS?
12:49:05.748396 IP (tos 0x0, ttl 64, id 57598, offset 0, flags [DF], proto TCP
(6), length 52)
127.0.0.1.52408 > 127.0.0.1.45773: Flags [F.], cksum 0xfe28 (incorrect ->
0x7f89), seq 62, ack 1, win 342, options [nop,nop,TS val 6743890 ecr 6743292],
length 0
E..4..@.@.[.N..Ezu.V.(.
.f.R.f..
---> RESPONSE
12:49:05.752416 IP (tos 0x0, ttl 64, id 14717, offset 0, flags [DF], proto TCP
(6), length 126)
127.0.0.1.45773 > 127.0.0.1.52408: Flags [P.], cksum 0xfe72 (incorrect ->
0x2820), seq 1:75, ack 63, win 342, options [nop,nop,TS val 6743890 ecr
6743890], length 74
E..~9}@.@...zu..N..F...V.r.
{noformat}
I'm assuming the "WHAT IS THIS" lines are TCP-level packets?
> Rust client fails to communicate with multiplexed perl/c_glib servers
> -
>
> Key: THRIFT-4451
> URL: https://issues.apache.org/jira/browse/THRIFT-4451
> Project: Thrift
> Issue Type: Bug
> Components: Rust - Library
>Reporter: Allen George
>Assignee: Allen George
>Priority: Major
>
> As stated in description. Minimal case is to comment out everything in the
> Rust {{test_client}} leaving only the {{SecondService}} call behind.
> From what I can tell the Rust socket isn't getting *any* bytes at all for the
> response (i.e. it can't even get the first 4 bytes of the message header).
> There is a {{flush()}} call on the remote side - so that's puzzling.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (THRIFT-4451) Rust client fails to communicate with multiplexed perl/c_glib servers
[
https://issues.apache.org/jira/browse/THRIFT-4451?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16407860#comment-16407860
]
Allen George commented on THRIFT-4451:
--
I'm noticing weird behavior where the rust client opens multiple tcp
connections to the perl server (as an example).
{noformat}
E..<..@.@.<.U!..._k..0.
[49/1830]
.f...f..
12:48:59.767657 IP (tos 0x0, ttl 64, id 36675, offset 0, flags [DF], proto TCP
(6), length 52)
127.0.0.1.52406 > 127.0.0.1.45773: Flags [.], cksum 0xfe28 (incorrect ->
0xe90b), seq 1, ack 1, win 342, options [nop,nop,TS val 6743292 ecr 6743292],
length 0
E..4.C@.@..~._k.U!.V.(.
.f...f..
12:48:59.767908 IP (tos 0x0, ttl 64, id 57595, offset 0, flags [DF], proto TCP
(6), length 60)
127.0.0.1.52408 > 127.0.0.1.45773: Flags [S], cksum 0xfe30 (incorrect ->
0xed41), seq 1325204487, win 43690, options [mss 65495,sackOK,TS val 6743292
ecr 0,nop,wscale 7], length 0
E..<..@.@.[.N0.
.f..
12:48:59.767923 IP (tos 0x0, ttl 64, id 0, offset 0, flags [DF], proto TCP (6),
length 60)
127.0.0.1.45773 > 127.0.0.1.52408: Flags [S.], cksum 0xfe30 (incorrect ->
0xafd8), seq 2054544767, ack 1325204488, win 43690, options [mss
65495,sackOK,TS val 6743292 ecr 6743292,nop,wscale 7], length 0
E..<..@.@.<.zu..N0.
.f...f..
12:48:59.767937 IP (tos 0x0, ttl 64, id 57596, offset 0, flags [DF], proto TCP
(6), length 52)
127.0.0.1.52408 > 127.0.0.1.45773: Flags [.], cksum 0xfe28 (incorrect ->
0x821d), seq 1, ack 1, win 342, options [nop,nop,TS val 6743292 ecr 6743292],
length 0
E..4..@.@.[.N...zu.V.(.
.f...f..
12:48:59.769584 IP (tos 0x0, ttl 64, id 36676, offset 0, flags [DF], proto TCP
(6), length 84)
127.0.0.1.52406 > 127.0.0.1.45773: Flags [P.], cksum 0xfe48 (incorrect ->
0x8b06), seq 1:33, ack 1, win 342, options [nop,nop,TS val 6743292 ecr
6743292], length 32
E..T.D@.@..]._k.U!.V.H.
.f...f..ThriftTest:testVoid.
12:48:59.769599 IP (tos 0x0, ttl 64, id 30002, offset 0, flags [DF], proto TCP
(6), length 52)
127.0.0.1.45773 > 127.0.0.1.52406: Flags [.], cksum 0xfe28 (incorrect ->
0xe8eb), seq 1, ack 33, win 342, options [nop,nop,TS val 6743292 ecr 6743292],
length 0
E..4u2@.@...U!..._kV.(.
.f...f..
12:48:59.771085 IP (tos 0x0, ttl 64, id 30003, offset 0, flags [DF], proto TCP
(6), length 73)
127.0.0.1.45773 > 127.0.0.1.52406: Flags [P.], cksum 0xfe3d (incorrect ->
0xc114), seq 1:22, ack 33, win 342, options [nop,nop,TS val 6743292 ecr
6743292], length 21
E..Iu3@.@..yU!..._kV.=.
.f...f..testVoid.
{noformat}
The above shows two different connections involved here. It's unclear if this
is the cause of the issues, but it explains why bytes being flushed out of the
perl server never seem to show up at the rust client.
FWIW, I *have* confirmed that the flushed bytes appear on the wire:
{noformat}
12:49:05.752416 IP (tos 0x0, ttl 64, id 14717, offset 0, flags [DF], proto TCP
(6), length 126)
127.0.0.1.45773 > 127.0.0.1.52408: Flags [P.], cksum 0xfe72 (incorrect ->
0x2820), seq 1:75, ack 63, win 342, options [nop,nop,TS val 6743890 ecr
6743890], length 74
E..~9}@.@...zu..N..F...V.r.
.f.R.f.RsecondtestString..("test_string").
{noformat}
> Rust client fails to communicate with multiplexed perl/c_glib servers
> -
>
> Key: THRIFT-4451
> URL: https://issues.apache.org/jira/browse/THRIFT-4451
> Project: Thrift
> Issue Type: Bug
> Components: Rust - Library
>Reporter: Allen George
>Assignee: Allen George
>Priority: Major
>
> As stated in description. Minimal case is to comment out everything in the
> Rust {{test_client}} leaving only the {{SecondService}} call behind.
> From what I can tell the Rust socket isn't getting *any* bytes at all for the
> response (i.e. it can't even get the first 4 bytes of the message header).
> There is a {{flush()}} call on the remote side - so that's puzzling.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
