[ https://issues.apache.org/jira/browse/CASSANDRA-6683?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13899277#comment-13899277 ]
Tyler Hobbs commented on CASSANDRA-6683: ---------------------------------------- [~brandon.williams] was our motivation for not calling {{sortByProximityWithScore}} every time just the overhead of that operation? It seems like it shouldn't have a large impact unless the RF is high. If we want to handle the high-RF case more efficiently, perhaps we could add a parameter that specifies how many of the replicas will be used (based on the consistency level) and just move the N lowest scores to the front if the first N scores aren't within BADNESS_THRESHOLD. > BADNESS_THRESHOLD does not working correctly with DynamicEndpointSnitch > ----------------------------------------------------------------------- > > Key: CASSANDRA-6683 > URL: https://issues.apache.org/jira/browse/CASSANDRA-6683 > Project: Cassandra > Issue Type: Bug > Components: Core > Environment: Linux 3.8.0-33-generic > Reporter: Kirill Bogdanov > Labels: snitch > Fix For: 2.0.6 > > > There is a problem in *DynamicEndpointSnitch.java* in > sortByProximityWithBadness() > Before calling sortByProximityWithScore we comparing each nodes score ratios > to the badness threshold. > {code} > if ((first - next) / first > BADNESS_THRESHOLD) > { > sortByProximityWithScore(address, addresses); > return; > } > {code} > This is not always the correct comparison because *first* score can be less > than *next* score and in that case we will compare a negative number with > positive. > The solution is to compute absolute value of the ratio: > {code} > if (Math.abs((first - next) / first) > BADNESS_THRESHOLD) > {code} > This issue causing an incorrect sorting of DCs based on their performance and > affects performance of the snitch. > Thanks. > -- This message was sent by Atlassian JIRA (v6.1.5#6160)