[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=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)
[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=16760185#comment-16760185 ] Allen George commented on THRIFT-1018: -- [~codesf] Not sure many people _want_ impotence :D > 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)
[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=16760184#comment-16760184 ] Randy Abernethy commented on THRIFT-1018: - Indeed, this would be complex to implement, particularly so in a generic way. Completely valid to want impotence but I concur with Allen, it should be an application layer concern. > 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)
[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=16760169#comment-16760169 ] Allen George commented on THRIFT-1018: -- I don't think it's worthwhile to support this. It would only work for the simplest cases, and my guess is that you'd encode these semantics into the application logic (which, IMO - is where it properly belongs). > 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)
[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=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)
