[
https://issues.apache.org/jira/browse/CASSANDRA-12311?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15406949#comment-15406949
]
Geoffrey Yu edited comment on CASSANDRA-12311 at 8/4/16 1:21 AM:
-----------------------------------------------------------------
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.
was (Author: geoffxy):
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)
