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