[jira] [Comment Edited] (CASSANDRA-6483) Possible Collections.sort assertion failure in STCS.filterColdSSTables

["graham sanderson (JIRA)" <ji...@apache.org>]

    [ https://issues.apache.org/jira/browse/CASSANDRA-6483?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13847129#comment-13847129 ] 

graham sanderson edited comment on CASSANDRA-6483 at 12/13/13 3:59 AM:
-----------------------------------------------------------------------

Adding my questions from dev-email thread

Note that the CASSANDRA-6109 feature claims to be “off” by default, however it isn’t immediately clear to me from that patch how “off” is implemented, and whether it is supposed to go down that code path even when “off"

I’m guessing there is no actual downside (other than ERROR level messages in the logs which cause alerts), since it just fails a subset of compactions?


was (Author: graham sanderson):
Adding my questions from dev-email thread

Note that the CASSANDRA-6109 feature claims to be “off” by default, however it isn’t immediately clear to me from that patch how “off” is implemented, and whether it is supposed to go down that code path even when “off"

I’m guessing there no actual downside (other than ERROR level messages in the logs which cause alerts), since it just fails a subset of compaction runs?

> Possible Collections.sort assertion failure in STCS.filterColdSSTables
> ----------------------------------------------------------------------
>
>                 Key: CASSANDRA-6483
>                 URL: https://issues.apache.org/jira/browse/CASSANDRA-6483
>             Project: Cassandra
>          Issue Type: Bug
>          Components: Core
>            Reporter: graham sanderson
>            Assignee: Tyler Hobbs
>              Labels: compaction
>             Fix For: 2.0.4
>
>
> We have observed the following stack trace periodically:
> {code}
> java.lang.IllegalArgumentException: Comparison method violates its general contract!
>         at java.util.TimSort.mergeLo(TimSort.java:747)
>         at java.util.TimSort.mergeAt(TimSort.java:483)
>         at java.util.TimSort.mergeCollapse(TimSort.java:410)
>         at java.util.TimSort.sort(TimSort.java:214)
>         at java.util.TimSort.sort(TimSort.java:173)
>         at java.util.Arrays.sort(Arrays.java:659)
>         at java.util.Collections.sort(Collections.java:217)
>         at org.apache.cassandra.db.compaction.SizeTieredCompactionStrategy.filterColdSSTables(SizeTieredCompactionStrategy.java:94)
>         at org.apache.cassandra.db.compaction.SizeTieredCompactionStrategy.getNextBackgroundSSTables(SizeTieredCompactionStrategy.java:59)
>         at org.apache.cassandra.db.compaction.SizeTieredCompactionStrategy.getNextBackgroundTask(SizeTieredCompactionStrategy.java:229)
>         at org.apache.cassandra.db.compaction.CompactionManager$BackgroundCompactionTask.run(CompactionManager.java:191)
>         at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:471)
>         at java.util.concurrent.FutureTask.run(FutureTask.java:262)
>         at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145)
>         at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615)
>         at java.lang.Thread.run(Thread.java:744)
> {code}
> The comparator ant SizeTieredCompactionStrategy line 94 breaks the assertions in the new JDK7 default sort algorithm, because (I think just) the hotness value (based on meter) may be modified concurrently by another thread
> This bug appears to have been introduced in CASSANDRA-6109



--
This message was sent by Atlassian JIRA
(v6.1.4#6159)