[
https://issues.apache.org/jira/browse/CASSANDRA-6483?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13847928#comment-13847928
]
Tyler Hobbs commented on CASSANDRA-6483:
----------------------------------------
bq. 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 answered this on the dev ML, but I'll repeat it here for others who are
interested. The default max_cold_reads_ratio is 0.0, so
{{filterColdSSTables()}} shouldn't filter any SSTables. When writing this
patch, I realized that even with that set to 0.0, SSTables that have no read
activity at all would still be filtered out. However, after this patch, that's
no longer true, and a setting of 0.0 will prevent any filtering at all.
bq. 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?
That's correct, this shouldn't cause any other problems, only delay some
compactions.
> 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
>
> Attachments: 6483-2.0-v1.patch
>
>
> 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)
