[jira] [Commented] (CASSANDRA-12075) Include whether or not the client should retry the request when throwing a RequestExecutionException
[ https://issues.apache.org/jira/browse/CASSANDRA-12075?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15347144#comment-15347144 ] Tyler Hobbs commented on CASSANDRA-12075: - Can you clarify what you intend the behavior to be? What are we going to consider retryable vs not? > Include whether or not the client should retry the request when throwing a > RequestExecutionException > > > Key: CASSANDRA-12075 > URL: https://issues.apache.org/jira/browse/CASSANDRA-12075 > Project: Cassandra > Issue Type: Improvement >Reporter: Geoffrey Yu >Assignee: Geoffrey Yu >Priority: Minor > > Some requests that result in an error should not be retried by the client. > Right now if the client gets an error, it has no way of knowing whether or > not it should retry. We can include an extra field in each > {{RequestExecutionException}} that will indicate whether the client should > retry, retry on a different host, or not retry at all. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CASSANDRA-12075) Include whether or not the client should retry the request when throwing a RequestExecutionException
[ https://issues.apache.org/jira/browse/CASSANDRA-12075?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15347976#comment-15347976 ] Sylvain Lebresne commented on CASSANDRA-12075: -- I think the idea is to indicate whether the query was idempotent in the first place or not. So a timeout on a counter update, or a list append would say it isn't. And I don't think that's crazy since currently client have to often rely on client declaring whether the query is idempotent since they don't parse queries (and kind of need to know on timeout for the purpose of retrying). That said, I think it's mostly useful for timeout exception, not all {{RequestExecutionException}} as I believe the other exceptions are precise enough for client to make their decision). I also don't think there is cases where we can meaningfully say it should be retried on a different host. But anyway, insofar as this ticket is about adding a boolean {{isIdemptotent}} to timeout exceptions, then I'm in favor of that. This is protocol v5 thing though. > Include whether or not the client should retry the request when throwing a > RequestExecutionException > > > Key: CASSANDRA-12075 > URL: https://issues.apache.org/jira/browse/CASSANDRA-12075 > Project: Cassandra > Issue Type: Improvement >Reporter: Geoffrey Yu >Assignee: Geoffrey Yu >Priority: Minor > > Some requests that result in an error should not be retried by the client. > Right now if the client gets an error, it has no way of knowing whether or > not it should retry. We can include an extra field in each > {{RequestExecutionException}} that will indicate whether the client should > retry, retry on a different host, or not retry at all. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CASSANDRA-12075) Include whether or not the client should retry the request when throwing a RequestExecutionException
[ https://issues.apache.org/jira/browse/CASSANDRA-12075?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15353915#comment-15353915 ] sankalp kohli commented on CASSANDRA-12075: --- If you get a Unavailable from co-ordinator, you should retry it on another host since this co-ordinator could be doing a long GC pause. We will be adding some more exceptions like throttles, too many tombstones exception and it will be good for driver to know whether it should be retying on a particular exception. This will be a better approach than driver special casing which exception to retry or not. Also with different implementations of the driver, it will be a lot helpful to not have this decision left to the client. > Include whether or not the client should retry the request when throwing a > RequestExecutionException > > > Key: CASSANDRA-12075 > URL: https://issues.apache.org/jira/browse/CASSANDRA-12075 > Project: Cassandra > Issue Type: Improvement >Reporter: Geoffrey Yu >Assignee: Geoffrey Yu >Priority: Minor > > Some requests that result in an error should not be retried by the client. > Right now if the client gets an error, it has no way of knowing whether or > not it should retry. We can include an extra field in each > {{RequestExecutionException}} that will indicate whether the client should > retry, retry on a different host, or not retry at all. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CASSANDRA-12075) Include whether or not the client should retry the request when throwing a RequestExecutionException
[ https://issues.apache.org/jira/browse/CASSANDRA-12075?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15354742#comment-15354742 ] Sylvain Lebresne commented on CASSANDRA-12075: -- bq. If you get a Unavailable from co-ordinator, you should retry it on another host since this co-ordinator could be doing a long GC pause Well, no. You *should* not, you *may*. An unavailable exception can also mean that there is genuinely not enough live nodes to perform the query (that's even the true original intent, even though a long GC pause can be indistinguishable from a genuinely dead node), in which case it makes no particular sense to retry. And that's kind of my point: what to do for that kind of situation is and should be client dependent, so I'm not a fan of "dictating" a behavior server side. So I'm all for adding more infos to the exceptions so client can have as much useful data as possible to do the decision (hence returning whether the query is {{idempotent}}, which is an objective data), but I disagree we should decide what should be done. And in the case of an unavailable exception for instance, I don't any more objective info we could send right now. bq. This will be a better approach than driver special casing which exception to retry or not. I disagree. I think it's exactly a responsibility of the driver to decide that kind of things. Rather, as hinted above, I think it's the client that should decide what he prefers and the driver should provide enough flexibility for the client to do what he wants. I'll also note that whatever we send, the driver will be at liberty to ignore it so we don't win much by including such "recommendation" to the protocol itself. I'm happy however to improve the protocol spec to provide recommendations. > Include whether or not the client should retry the request when throwing a > RequestExecutionException > > > Key: CASSANDRA-12075 > URL: https://issues.apache.org/jira/browse/CASSANDRA-12075 > Project: Cassandra > Issue Type: Improvement >Reporter: Geoffrey Yu >Assignee: Geoffrey Yu >Priority: Minor > > Some requests that result in an error should not be retried by the client. > Right now if the client gets an error, it has no way of knowing whether or > not it should retry. We can include an extra field in each > {{RequestExecutionException}} that will indicate whether the client should > retry, retry on a different host, or not retry at all. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CASSANDRA-12075) Include whether or not the client should retry the request when throwing a RequestExecutionException
[ https://issues.apache.org/jira/browse/CASSANDRA-12075?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15355864#comment-15355864 ] sankalp kohli commented on CASSANDRA-12075: --- By driver you mean Java Driver, Python driver, etc and by client you mean application code talking to C* right? Say we send out TombstoneOverwhelmingException to driver, it should definitely not retry on its own no matter what retry policy the client code provide. Now we cannot stop client code from sending the same request again. Same example can be made with some other type of throttles as well. I agree that other examples are recommendations but these 2 are not. I am fine closing this JIRA and making these part of exceptions which driver can interpret and will not retry? What do you think > Include whether or not the client should retry the request when throwing a > RequestExecutionException > > > Key: CASSANDRA-12075 > URL: https://issues.apache.org/jira/browse/CASSANDRA-12075 > Project: Cassandra > Issue Type: Improvement >Reporter: Geoffrey Yu >Assignee: Geoffrey Yu >Priority: Minor > > Some requests that result in an error should not be retried by the client. > Right now if the client gets an error, it has no way of knowing whether or > not it should retry. We can include an extra field in each > {{RequestExecutionException}} that will indicate whether the client should > retry, retry on a different host, or not retry at all. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CASSANDRA-12075) Include whether or not the client should retry the request when throwing a RequestExecutionException
[ https://issues.apache.org/jira/browse/CASSANDRA-12075?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15357189#comment-15357189 ] Sylvain Lebresne commented on CASSANDRA-12075: -- bq. By driver you mean Java Driver, Python driver, etc and by client you mean application code talking to C* right? Generally yes, though I tend to use both interchangeably since it's kind of the same as far as the server is concerned. bq. Say we send out TombstoneOverwhelmingException to driver, it should definitely not retry on its own no matter what retry policy the client code provide. Sure, but it's easy enough to just document that in the spec. Shipping a boolean doesn't really achieve anything since a crappy driver implementation can still ignore whatever we send, and a good implementation likely won't get that wrong in the first place. bq. Same example can be made with some other type of throttles as well Well, that's not even in yet, so let's not anticipate too much. Besides, on a "throttle exception", I would disagree that there is a single "right" course of action. Maybe trying the next node is good for some client, but other may prefer just throttling themselves as a result, bq. I am fine closing this JIRA and making these part of exceptions which driver can interpret and will not retry? Not sure I understand what you mean by that. But what I would personally do on that whole question is: # add to write timeout exceptions if the query was idempotent or not, as that's an important information regarding retries that would be useful to drivers but they don't have easily. # improve the protocol spec (and or maybe write a "recommendation for drivers author" doc) to specify for each exception we can return what can be sensibly be done about them (and what isn't sensible). But shipping some kind of enum telling drivers what they *must* do will imo be too limiting for most exceptions, and we can't guarantee drivers will respect them anyway (so why ship it on the wire every time? Let's just document it). > Include whether or not the client should retry the request when throwing a > RequestExecutionException > > > Key: CASSANDRA-12075 > URL: https://issues.apache.org/jira/browse/CASSANDRA-12075 > Project: Cassandra > Issue Type: Improvement >Reporter: Geoffrey Yu >Assignee: Geoffrey Yu >Priority: Minor > > Some requests that result in an error should not be retried by the client. > Right now if the client gets an error, it has no way of knowing whether or > not it should retry. We can include an extra field in each > {{RequestExecutionException}} that will indicate whether the client should > retry, retry on a different host, or not retry at all. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CASSANDRA-12075) Include whether or not the client should retry the request when throwing a RequestExecutionException
[ https://issues.apache.org/jira/browse/CASSANDRA-12075?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15358301#comment-15358301 ] sankalp kohli commented on CASSANDRA-12075: --- Sure we can document it. The only thing is that if we add an exception which we dont want good drivers to not retry, we also need to patch the driver right away for this to work. Example: Say we add an exception which we dont want driver to retry. Now we will need to do changes in driver code and deploy this to the application. Normally client deployment are less infrequent as it is not in the control of the team running Cassandra. > Include whether or not the client should retry the request when throwing a > RequestExecutionException > > > Key: CASSANDRA-12075 > URL: https://issues.apache.org/jira/browse/CASSANDRA-12075 > Project: Cassandra > Issue Type: Improvement >Reporter: Geoffrey Yu >Assignee: Geoffrey Yu >Priority: Minor > > Some requests that result in an error should not be retried by the client. > Right now if the client gets an error, it has no way of knowing whether or > not it should retry. We can include an extra field in each > {{RequestExecutionException}} that will indicate whether the client should > retry, retry on a different host, or not retry at all. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CASSANDRA-12075) Include whether or not the client should retry the request when throwing a RequestExecutionException
[ https://issues.apache.org/jira/browse/CASSANDRA-12075?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15358302#comment-15358302 ] sankalp kohli commented on CASSANDRA-12075: --- Lets add idempotent thing for now > Include whether or not the client should retry the request when throwing a > RequestExecutionException > > > Key: CASSANDRA-12075 > URL: https://issues.apache.org/jira/browse/CASSANDRA-12075 > Project: Cassandra > Issue Type: Improvement >Reporter: Geoffrey Yu >Assignee: Geoffrey Yu >Priority: Minor > > Some requests that result in an error should not be retried by the client. > Right now if the client gets an error, it has no way of knowing whether or > not it should retry. We can include an extra field in each > {{RequestExecutionException}} that will indicate whether the client should > retry, retry on a different host, or not retry at all. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CASSANDRA-12075) Include whether or not the client should retry the request when throwing a RequestExecutionException
[ https://issues.apache.org/jira/browse/CASSANDRA-12075?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15358724#comment-15358724 ] Sylvain Lebresne commented on CASSANDRA-12075: -- bq. The only thing is that if we add an exception which we dont want good drivers to not retry, we also need to patch the driver right away for this to work. Well, you have to change the native protocol to add any exception and that require a driver change anyway. > Include whether or not the client should retry the request when throwing a > RequestExecutionException > > > Key: CASSANDRA-12075 > URL: https://issues.apache.org/jira/browse/CASSANDRA-12075 > Project: Cassandra > Issue Type: Improvement >Reporter: Geoffrey Yu >Assignee: Geoffrey Yu >Priority: Minor > > Some requests that result in an error should not be retried by the client. > Right now if the client gets an error, it has no way of knowing whether or > not it should retry. We can include an extra field in each > {{RequestExecutionException}} that will indicate whether the client should > retry, retry on a different host, or not retry at all. -- This message was sent by Atlassian JIRA (v6.3.4#6332)