[
https://issues.apache.org/jira/browse/THRIFT-5030?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Jens Geyer updated THRIFT-5030:
-------------------------------
Summary: Add possibility for TMessage seqid verification in the processor
function (was: netstd: Add possibility for TMessage seqid verification in the
processor function)
> 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
> Components: netstd - Library
> Reporter: Paulo Neves
> Assignee: Paulo Neves
> Priority: Major
> Time Spent: 20m
> Remaining Estimate: 0h
>
> 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)
