[
https://issues.apache.org/jira/browse/CASSANDRA-3722?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13217657#comment-13217657
]
Jonathan Ellis commented on CASSANDRA-3722:
-------------------------------------------
bq. Taking into account the number of outstanding requests is IMO a necessity
It sounds like you're saying that if coordinator X has 1000 requests pending
response from replica Y, and only 100 to replica Z, then X should suspect that
Y is having trouble and rely more heavily on Z, even before requests to Y start
timing out. Right?
That sounds reasonable to me in theory. How do we mix that into the existing
latency information we track for dsnitch?
> Send Hints to Dynamic Snitch when Compaction or repair is going on for a node.
> ------------------------------------------------------------------------------
>
> Key: CASSANDRA-3722
> URL: https://issues.apache.org/jira/browse/CASSANDRA-3722
> Project: Cassandra
> Issue Type: Improvement
> Components: Core
> Affects Versions: 1.1.0
> Reporter: Vijay
> Assignee: Vijay
> Priority: Minor
>
> Currently Dynamic snitch looks at the latency for figuring out which node
> will be better serving the requests, this works great but there is a part of
> the traffic sent to collect this data... There is also a window when Snitch
> doesn't know about some major event which are going to happen on the node
> (Node which is going to receive the data request).
> It would be great if we can send some sort hints to the Snitch so they can
> score based on known events causing higher latencies.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
