[
https://issues.apache.org/jira/browse/CASSANDRA-12311?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15423537#comment-15423537
]
Tyler Hobbs commented on CASSANDRA-12311:
-----------------------------------------
The Jenkins job errored while collecting log files at the end, but looking at
the full console output, there were only two test errors/failures:
* {{resumable_rebuild_test}}
* {{test_basic_snapshot_and_restore}} \(?\)
The first is a known, unrelated error. I'm not entirely sure if the second one
actually had an error, because there's not a proper stacktrace and error
message.
I've restarted the job again to hopefully clear this up, but it looks like the
tests will be okay.
> 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-dtest.txt, 12311-trunk-v2.txt, 12311-trunk-v3.txt,
> 12311-trunk-v4.txt, 12311-trunk-v5.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)
