You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@thrift.apache.org by "James E. King III (JIRA)" <ji...@apache.org> on 2019/02/02 00:38:00 UTC

[jira] [Commented] (THRIFT-1018) Add support for idempotent service requests

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

James E. King III commented on THRIFT-1018:
-------------------------------------------

The closest thing would be to attempt to retry a request with the same sequence number, but thrift has no debouncing notions on the server side like, say, NFS does.

> Add support for idempotent service requests
> -------------------------------------------
>
>                 Key: THRIFT-1018
>                 URL: https://issues.apache.org/jira/browse/THRIFT-1018
>             Project: Thrift
>          Issue Type: New Feature
>          Components: Wish List
>         Environment: NA
>            Reporter: Tony Kinnis
>            Priority: Major
>
> I would like to be able to flag service methods as idempotent and allow the transport to replay idempotent requests in certain failure cases. I think this would be a valuable feature for Thrift and its community of users.
> High-Level Feature Description:
> Owners of services should be able to flag a service method as idempotent in the IDL. This metadata will need to make its way into the code generated by the compiler. Exactly how that shows up is probably language dependent.
> The transport can then transparently replay the idempotent requests for typical errors, such as connect timeout, interrupted connections, no response received in timeout interval, etc. 
> The replaying of idempotent requests can be disabled/enabled via the transport. In addition to enabling/disabling, the configuration could allow for the number of allowed retries to be specified or even provide a delegate method that decides if the retry is allowed based on the error that occurred and other context. 
> In some cases retries are not desired, even if the method allows for it. In this case the caller can simply disable retries. Likewise, the caller can decide to only retry on a subset of the possible errors by providing a delegate to the transport.



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