You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@thrift.apache.org by "Ashutosh Chauhan (JIRA)" <ji...@apache.org> on 2012/06/23 03:08:43 UTC

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

    [ https://issues.apache.org/jira/browse/THRIFT-1250?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13399777#comment-13399777 ] 

Ashutosh Chauhan commented on THRIFT-1250:
------------------------------------------

Is there any progress on this? Someone actively working on it? I also need this feature. Can someone care to comment if its an architecture decision not to support it or is is just that feature is waiting to be taken up and implemented by some brave engineer. 
                
> 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: Jake Farrell
>
> 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 is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira