cassandra-commits mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Sylvain Lebresne (JIRA)" <>
Subject [jira] [Commented] (CASSANDRA-9519) CASSANDRA-8448 Doesn't seem to be fixed
Date Thu, 09 Jul 2015 11:45:05 GMT


Sylvain Lebresne commented on CASSANDRA-9519:

bq. I think this should be enough to fix it.

If it is, I don't understand why, so you might want to elaborate what the problem is and why
that fixes it.

What I personally think the problem is is that while CASSANDRA-8448 made the {{scores}} map
copy-on-write, we're still accessing the volatile/shared {{scores}} reference in {{compareEndpoints}},
so successive calls to that method may return different results for the same inputs (because
scores have changed) and to the best of my knowledge that's the "contract" that {{Collections.sort}}
bitch about breaking. In other words, we need to ensure that during a given call to {{Collections.sort}},
the result of {{compareEndpoints}} should be stable (return the same output for the same inputs).
In other words, all calls to {{compareEndpoints}} used by a call to {{sortByProximity}} should
use the same scores. Meaning that we should grabe a reference to the {{scores}} map at the
beginning of {{sortByProximity}} and only use that.

I've pushed a patch doing that [here|]. It's
worth noting that we can't do that with the {{compareEndpoints}} signature exposed by {{IEndpointSnitch}}
since we need to pass it the (immutable) {{scores}} map. So the public {{DynamicEndpointSnitch.compareEndpoints()}}
method now throw an {{UnsupportedOperationException}}. Which, is worth noting, could be a
problem if custom snitch implementation are wrapping the dynamic snitch and use that {{compareEndpoints}}
method (or if something wrap a dynamic snitch with a dynamic snitch, but I think we're cool
with refusing that). I don't see why you'd wrap the dynamic snitch so it's probably fine,
but worth mentioning nonetheless.

> CASSANDRA-8448 Doesn't seem to be fixed
> ---------------------------------------
>                 Key: CASSANDRA-9519
>                 URL:
>             Project: Cassandra
>          Issue Type: Bug
>          Components: Core
>            Reporter: Jeremiah Jordan
>             Fix For: 2.1.x, 2.2.x
>         Attachments: 9519.txt
> Still seeing the "Comparison method violates its general contract!" in 2.1.5
> {code}
> java.lang.IllegalArgumentException: Comparison method violates its general contract!
> 	at java.util.TimSort.mergeHi( ~[na:1.8.0_45]
> 	at java.util.TimSort.mergeAt( ~[na:1.8.0_45]
> 	at java.util.TimSort.mergeCollapse( ~[na:1.8.0_45]
> 	at java.util.TimSort.sort( ~[na:1.8.0_45]
> 	at java.util.Arrays.sort( ~[na:1.8.0_45]
> 	at java.util.ArrayList.sort( ~[na:1.8.0_45]
> 	at java.util.Collections.sort( ~[na:1.8.0_45]
> 	at org.apache.cassandra.locator.AbstractEndpointSnitch.sortByProximity(
> 	at org.apache.cassandra.locator.DynamicEndpointSnitch.sortByProximityWithScore(
> 	at org.apache.cassandra.locator.DynamicEndpointSnitch.sortByProximityWithBadness(
> 	at org.apache.cassandra.locator.DynamicEndpointSnitch.sortByProximity(
> 	at org.apache.cassandra.service.StorageProxy.getLiveSortedEndpoints(
> 	at org.apache.cassandra.service.StorageProxy.getRangeSlice( ~[cassandra-all-]
> 	at org.apache.cassandra.cql3.statements.SelectStatement.execute(
> 	at org.apache.cassandra.cql3.statements.SelectStatement.execute(
> 	at org.apache.cassandra.cql3.statements.SelectStatement.execute(
> 	at org.apache.cassandra.cql3.QueryProcessor.processStatement(
> 	at org.apache.cassandra.cql3.QueryProcessor.process( ~[cassandra-all-]
> 	at org.apache.cassandra.cql3.QueryProcessor.process( ~[cassandra-all-]
> {code}

This message was sent by Atlassian JIRA

View raw message