[jira] [Commented] (CASSANDRA-12311) Propagate TombstoneOverwhelmingException to the client

["Tyler Hobbs (JIRA)" <ji...@apache.org>]

    [ https://issues.apache.org/jira/browse/CASSANDRA-12311?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15405018#comment-15405018 ] 

Tyler Hobbs commented on CASSANDRA-12311:
-----------------------------------------

I think the idea of generalizing this to support error codes is good.  However, I think we should sort a few things out ahead of time.

Ideally, we will have many more error codes than just the one for tombstone overwhelming.  If these are described as part of the native protocol spec, then new error codes should only really be introduced in new native protocol versions.  However, that seems like it might be overly restrictive.  I wonder if perhaps the native protocol spec should just say "this is a one-byte error code; for the meaning of the error code, look at <link to cassandra docs page>".  Of course, this means that drivers probably would _not_ handle error codes in a fancy way (such as tying error messages to particular codes), which is a downside.  One upside to error codes is that they are easily googleable, though, so users could presumably figure out the meaning quickly.

Second, we may want to combine this improvement with another one that I've been thinking of.  Instead of having a single byte error code, we should return a map of endpoints to failure codes.  Besides handling multiple types of failures correctly, this would let users know which replica nodes actually had problems, which is something the current errors don't do.

Third, I think we should go with a two-byte error code.  It's used rarely, so the space doesn't matter, and a single byte may become restrictive over time.

Last, I haven't had time to verify this, but it seems like the messaging service changes may have to wait until 4.0?  I'm not sure if new parameters are handled gracefully by nodes that don't know them yet.

> Propagate TombstoneOverwhelmingException to the client
> ------------------------------------------------------
>
>                 Key: CASSANDRA-12311
>                 URL: https://issues.apache.org/jira/browse/CASSANDRA-12311
>             Project: Cassandra
>          Issue Type: Improvement
>            Reporter: Geoffrey Yu
>            Assignee: Geoffrey Yu
>            Priority: Minor
>             Fix For: 4.x
>
>         Attachments: 12311-trunk-v2.txt, 12311-trunk.txt
>
>
> Right now if a data node fails to perform a read because it ran into a {{TombstoneOverwhelmingException}}, it only responds back to the coordinator node with a generic failure. Under this scheme, the coordinator won't be able to know exactly why the request failed and subsequently the client only gets a generic {{ReadFailureException}}. It would be useful to inform the client that their read failed because we read too many tombstones. We should have the data nodes reply with a failure type so the coordinator can pass this information to the client.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)