[
https://issues.apache.org/jira/browse/THRIFT-1250?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Diwaker Gupta updated THRIFT-1250:
----------------------------------
Description:
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.
was:
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:
<pre>
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;
}
</pre>
IMO this would simplify the implementation of features like duplicate
detection, RPC retries, multiple-outstanding RPCs etc.
> 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
>
> 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.
For more information on JIRA, see: http://www.atlassian.com/software/jira
