thrift-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Jens Geyer (JIRA)" <j...@apache.org>
Subject [jira] [Commented] (THRIFT-1018) Add support for idempotent service requests
Date Mon, 04 Feb 2019 21:35:00 GMT

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

Jens Geyer commented on THRIFT-1018:
------------------------------------

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

Mime
View raw message