[jira] [Closed] (THRIFT-1250) RPC enhancements: multiple-outstanding, retries, error code etc

["James E. King III (JIRA)" <ji...@apache.org>]

     [ https://issues.apache.org/jira/browse/THRIFT-1250?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

James E. King III closed THRIFT-1250.
-------------------------------------
    Resolution: Not A Problem
      Assignee: James E. King III  (was: Jake Farrell)

I suspect most of these issues are resolved now.  If a transport error occurs, you get a TTransportException.  If the remote method is not found you get a TProtocolException.  If a handler exception occurs you get a TApplicationException.  You can retry any call that fails.

Some languages support multiple outstanding requests.  Those that do must send a unique sequence ID with each request (unique for that connection).  Some language servers support returning the sequence id that was sent in the request - I can't guarantee that all of the do at this time since there's no cross test for it.  There's a backlog item for that.

> RPC enhancements: multiple-outstanding, retries, error code etc
> ---------------------------------------------------------------
>
>                 Key: THRIFT-1250
>                 URL: https://issues.apache.org/jira/browse/THRIFT-1250
>             Project: Thrift
>          Issue Type: Improvement
>          Components: Compiler (General)
>            Reporter: Diwaker Gupta
>            Assignee: James E. King III
>            Priority: Major
>
> The current RPC model of Thrift sends the RPC requests and responses as-is, leaving all the smartness to the Processor implementation. While this model has the benefit of simplicity, it does have some limitations. In particular:
> * There's no easy way for applications to retry a failed RPC. In fact, there's no easy way for the RPC layer to even communicate problems to the application (was there a transport error? did the invoked method not exist on the remote end? some other application-specific error? time out?).
> * Supporting multiple-outstanding RPCs is challenging, because the RPC layer doesn't uniquely identify outgoing RPC requests. So when a response comes back, there's no way to associate it with one of the outstanding RPCs.
> A fairly straight-forward approach to address these issues would be to encapsulate the RPC request/response in a wrapper with some additional metadata. In fact, this metadata can itself be specified as a Thrift message. Concretely, something like this:
> {code}
> struct RpcRequest {
> // metadata
> 1: required i64 id;
> // optional -- may be used to sanity check
> 2: i32 requestSize; // including payload
> 3: i32 payloadSize; // just the payload
> // actual request, serialized
> 2: required binary payload;
> }
> {code}
> IMO this would simplify the implementation of features like duplicate detection, RPC retries, multiple-outstanding RPCs etc.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)