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

Reply via email to