You are viewing a plain text version of this content. The canonical link for it is here.
Posted to commits@cassandra.apache.org by "Sylvain Lebresne (JIRA)" <ji...@apache.org> on 2016/07/29 14:48:20 UTC
[jira] [Commented] (CASSANDRA-12311) Propagate
TombstoneOverwhelmingException to the client
[ https://issues.apache.org/jira/browse/CASSANDRA-12311?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15399436#comment-15399436 ]
Sylvain Lebresne commented on CASSANDRA-12311:
----------------------------------------------
I'm wondering if it's worth adding a totally new exception. I agree {{ReadFailureException}} is currently a bit too imprecise regarding it's details, but it's not necessarily only true of {{TombstoneOverwhelmingException}}, and the latter is still a read failure exception. I think I'd have a preference for adding a (potentially optional) {{cause}} to the existing {{ReadFailureException}}.
> 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.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)