[
https://issues.apache.org/jira/browse/THRIFT-5030?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16987288#comment-16987288
]
Jens Geyer edited comment on THRIFT-5030 at 12/3/19 9:48 PM:
-------------------------------------------------------------
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 needed, in any arbitrary order?
{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. If this
is about session management, that's not the business of Thrift. That should be
application logic.
was (Author: jensg):
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)
