You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@thrift.apache.org by "Allen George (JIRA)" <ji...@apache.org> on 2018/03/21 12:59:00 UTC
[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&focusedCommentId=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..<..@.@.[.............N............0.........
.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..N........0.........
.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!..._k....V.(.....
.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@.@..y............U!..._k....V.=.....
.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.R........secondtestString..........&allen-return-testString("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)