[
https://issues.apache.org/jira/browse/CASSANDRA-16850?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17400474#comment-17400474
]
Blake Eggleston commented on CASSANDRA-16850:
---------------------------------------------
bq. you are saying the global one should as well?
Sure, I think so, though I think we need a top level "Aborts" meter if we have
the component ones
bq. I think we could do Map<String, Meter> where the string is the simple name
of the class?
That sounds a little brittle. If you're worried about complicating exception
handling, you could add a method to {{ClientRequestMetrics}} that accepts an
exception and marks the appropriate field.
Also, I think the change to ReadCommand.trackWarnings should be reverted (and
the later change to LocalReadRunnable). Adding a config flag to turn the client
warnings on/off is a good idea, but it should be applied at the coordinator,
and the replicas should do what the coordinator asks. That includes the local
runnable too, the coordinator should tell the local runnable whether to track
warnings or not. Since an incorrectly interpreted flag would result in an
incorrect client response, we shouldn't leave any room for race edge cases.
> Add client warnings and abort to tombstone and coordinator reads which go
> past a low/high watermark
> ---------------------------------------------------------------------------------------------------
>
> Key: CASSANDRA-16850
> URL: https://issues.apache.org/jira/browse/CASSANDRA-16850
> Project: Cassandra
> Issue Type: Improvement
> Components: Observability/Logging
> Reporter: David Capwell
> Assignee: David Capwell
> Priority: Normal
> Fix For: 4.1
>
> Time Spent: 20m
> Remaining Estimate: 0h
>
> We currently will abort queries if we hit too many tombstones, but its common
> that we would want to also warn clients (client warnings) about this before
> we get that point; its also common that different logic would like to be able
> to warn/abort about client options (such as reading a large partition). To
> allow this we should add a concept of low/high watermarks (warn/abort) to
> tombstones and coordinator reads.
> Another issue is that current aborts look the same as a random failure, so
> from an SLA point of view it would be good to differentiate between user
> behavior being rejected and unexplained issue.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
