[
https://issues.apache.org/jira/browse/THRIFT-5030?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16983061#comment-16983061
]
Jens Geyer commented on THRIFT-5030:
------------------------------------
Just tossing an idea ... what if we add a setter to the client that can be used
to seed the {{TBaseClient._seqId}} field? That way you can initialize the
clients in some fashion that its more likely to minimize collisions: e.g. you
have 10 clients then seed each one with something along {{clientNr *
int.MaxValue / 10}} to distribute them evenly across the available range. The
used ranges will overlap, but seqID was never designed to be an UUID anyway.
> 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)
