[
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)
