Paulo Neves created THRIFT-5030:
-----------------------------------
Summary: netstd: Add possibility for TMessage seqid verification
in the processor function
Key: THRIFT-5030
URL: https://issues.apache.org/jira/browse/THRIFT-5030
Project: Thrift
Issue Type: Improvement
Reporter: Paulo Neves
Currently we have a seqid system that is sent from the client to the server,
and retrieved back. The specification says that the seqid returned by the
server should be the same sent by the client. Currently this seems to be the
case on the server side, but the client side never verifies this to be true.
I have a pull request that changes that situation for netstd. The client side
verification is useful for when a common transport is being used for multiple
client calls. This should be legal as the processor and transport are separate
architectural units. If another client makes an RPC then we may get messages
which are not addressed to us. We should have a way to let the client caller
know that such event happened.
Another way to do this is to make this verification in a protocol decorator,
that completely manages the seqid by itself. I also have an implementation for
this case, but i have not prepared the pull request yet. Please let me know
which approach do you prefer.
Personally I have gone the way of the protocol decorator as it solves other
issues like seqid collision due to all the TBaseClient initialization starting
with seqid == 1. With the protocol decorator I was then able to fast skip the
message which was not replied with the expected seqid.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
