[
https://issues.apache.org/jira/browse/THRIFT-5030?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16987288#comment-16987288
]
Jens Geyer commented on THRIFT-5030:
------------------------------------
Any news?
BTW, I'm still curious when this below could occur. Do you have an example at
hand? I never observed multiple calls to one server as being a problem, because
that's what RPC servers are for, aren't they? To provide an endpoint that can
be called by as many clients as possible?
{quote}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
{quote}
Maybe a test case could help to show the issue and verify the solution.
> 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)
