[
https://issues.apache.org/jira/browse/THRIFT-5812?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17875231#comment-17875231
]
Jens Geyer commented on THRIFT-5812:
------------------------------------
I haven't checked the testcase (thanks for preparing it), but something
immediately popped up ... there are certain server-side elements that
implicitly require client-side usage of {*}{{TFramedTransport}}{*}. Could that
be the case here? Just educated guesswork here, it might as well be sth else,
but that's a common trap.
PS: That's one reason for [THRIFT-5778]
> Capacity overflow in Rust server
> --------------------------------
>
> Key: THRIFT-5812
> URL: https://issues.apache.org/jira/browse/THRIFT-5812
> Project: Thrift
> Issue Type: Bug
> Components: Rust - Library
> Affects Versions: 0.17.0, 0.20.0
> Reporter: Victor
> Priority: Major
>
> I am trying to interact with a Rust Thrift server using a Java client. When
> using the sync client, the server misreads the length of the message and
> panics with a capacity overflow error. However, the async client works fine
> for some reason. It happens on both the compact and binary protocols.
> When handling a request, the processor calls the protocol’s
> {{{}read_message_begin{}}}, which calls the transport’s {{{}read{}}}. There,
> it reads an i32 to check the message length. At this step, for some reason,
> when the message has been sent with a sync client, it reads {{82 21 01 04}}
> (the Thrift header, that contains the protocol version, message type and
> sequence id), when it has been sent with an async client, it reads {{00 00 00
> 09}} (which is the right length).
> When analysing the packets, it seems that the only difference (apart from the
> TCP headers) in both protocols is the seqid, which turns out to be 0 with the
> async client, 1 with the sync client.
> -I am not sure whether this is an issue on the Rust or Java side (although I
> think Rust).- I found [a
> topic|https://users.rust-lang.org/t/first-rust-thrift-server-crashing-on-returning-i32/83271]
> on this issue that also has the problem with clients in other languages so
> it probably comes from the Rust library. -Also I am reporting it on version
> 0.17.0 because it is the latest available version of thrift on crates.io.-
> The issue also occurs when using the latest 0.21.0 Rust library (commit
> e98d6b1).
> See here for more details and a reproducible example:
> [https://github.com/victorbnl/thrift-rs-capacity-overflow].
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
