[
https://issues.apache.org/jira/browse/THRIFT-1018?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16760244#comment-16760244
]
Jens Geyer edited comment on THRIFT-1018 at 2/4/19 9:38 PM:
------------------------------------------------------------
[https://github.com/grpc/grpc/issues/5471]
Never implemented, just closed. That should leave some clues.
I would do the same. Allen already hit the nail why.
PS: There's also [https://github.com/grpc/grpc/issues/12038] which is still
open.
was (Author: jensg):
[https://github.com/grpc/grpc/issues/5471]
Never implemented, just closed. That should leave some clues.
I would do the same. Allen already hit the nail why.
> 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)
