cassandra-commits mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Geoffrey Yu (JIRA)" <j...@apache.org>
Subject [jira] [Updated] (CASSANDRA-12311) Propagate TombstoneOverwhelmingException to the client
Date Thu, 04 Aug 2016 01:20:20 GMT

     [ https://issues.apache.org/jira/browse/CASSANDRA-12311?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]

Geoffrey Yu updated CASSANDRA-12311:
------------------------------------
    Attachment: 12311-trunk-v3.txt

Those ideas sound good to me. I can see how having extensibility in the failure codes can
be useful so that we don't need to wait for protocol version bumps. Also passing back an endpoint
to failure code map would be nice since we won't need to interpret the potentially different
responses from the replicas at the coordinator to determine which (single) failure code should
be used.

I attached a patch with those changes incorporated. Since we need to pass some sort of failure
code back from the replicas, I wanted to use the same set of failure codes between nodes as
between the client and coordinator. So I placed the codes in a new enum {{RequestFailureReason}}
and placed the map under {{RequestFailureException}}, meaning {{WriteFailureException}}s will
carry this endpoint to failure code map as well. Please let me know what you think.

> 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
>              Labels: client-impacting, doc-impacting
>             Fix For: 4.x
>
>         Attachments: 12311-trunk-v2.txt, 12311-trunk-v3.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)

Mime
View raw message