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