cassandra-commits mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Tyler Hobbs (JIRA)" <>
Subject [jira] [Commented] (CASSANDRA-12311) Propagate TombstoneOverwhelmingException to the client
Date Fri, 05 Aug 2016 21:17:20 GMT


Tyler Hobbs commented on CASSANDRA-12311:

Your latest patch looks good, thank you.

bq. I took a look at the dtests but, since this changes the encoding for the client facing
protocol, won't the python driver will need to be changed first to recognize the new failure
code map?

Ah, yes, that's a good point.  If you're comfortable with python and would like to open a
pull request to add support for this, please feel free to.  Otherwise, I can take care of
that pretty quickly.  (Note: any driver work would need to be on top of
for general protocol v5 support.)

> Propagate TombstoneOverwhelmingException to the client
> ------------------------------------------------------
>                 Key: CASSANDRA-12311
>                 URL:
>             Project: Cassandra
>          Issue Type: Improvement
>            Reporter: Geoffrey Yu
>            Assignee: Geoffrey Yu
>            Priority: Minor
>              Labels: client-impacting, doc-impacting
>             Fix For: 4.x
>         Attachments: 12311-trunk-v2.txt, 12311-trunk-v3.txt, 12311-trunk-v4.txt, 12311-trunk-v5.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

View raw message