thrift-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Jens Geyer (Jira)" <>
Subject [jira] [Commented] (THRIFT-5030) Add possibility for TMessage seqid verification in the processor function
Date Wed, 27 Nov 2019 01:18:00 GMT


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:
>             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

View raw message