dengzhhu653 commented on PR #3127: URL: https://github.com/apache/thrift/pull/3127#issuecomment-2840443918
Thank you @Jens-G! Here is my understanding, please correct me if wrong. The `TFramedTransport` takes in `innerTransport` as the source transport, the message limit will check at the source, this `TFramedTransport` will validate the frame limit only. For the frame limit we can get from the `innerTransport` if any, otherwise default, it's missing in current PR. > Another example would be compression implemented as a layered transport This is a good case. TZlibTransport for example, it still checks the message limit after the de-compression. we still allow the user to implement their own message limit based on their needs, for example: https://github.com/apache/thrift/blob/05b0659884a839e38789ba2ca5cdeb25efe6c992/lib/java/src/test/java/org/apache/thrift/protocol/ProtocolTestBase.java#L563-L567 > no matter how much more data the socket would be able to deliver. This is by design. An issue I can think of is how to distinguish different messages a socket might send, a Hive client can re-use the same socket for future uses, either for a different request or polling the request's status from the server. -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: [email protected] For queries about this service, please contact Infrastructure at: [email protected]
