On Fri, Apr 10, 2015 at 8:34 PM, Ariel Weisberg <ariel.weisb...@datastax.com > wrote:
> Hi Marcus, > > CASSANDRA-8211 <https://issues.apache.org/jira/browse/CASSANDRA-8211> > Overlapping > sstables in L1+ > > So the question I would ask is would the workload that reproduces this > specific bug be interesting in the general sense. Do we have to do anything > special to reproduce it like make many non-verlapping sstables in L0 and is > that interesting in the general sense. > The way I reproduced it was (and I doubt it is interesting in the general case) * insert 10M keys with stress * major compact * stop node * sstablesplit * start node * switch to LCS * wait, repeat if no error within 5 minutes ie, very specific to the bug > > CASSANDRA-8320 <https://issues.apache.org/jira/browse/CASSANDRA-8320> > 2.1.2: NullPointerException in SSTableWriter > > What tests did we add for this? Is it a targeted regression test, or are we > now fully exercising SSTableRewriter the way users do against > representative configurations and data? > > Yes, we added unit tests that exercises the code in SSTableRewriter > CASSANDRA-8432 <https://issues.apache.org/jira/browse/CASSANDRA-8432> > Standalone > Scrubber broken for LCS > > OK great. Looks like I didn't need to ask Jeremiah to do to look at the > offline tools. > > CASSANDRA-8386 <https://issues.apache.org/jira/browse/CASSANDRA-8386> Make > sure we release references to sstables after incremental repair > CASSANDRA-8316 <https://issues.apache.org/jira/browse/CASSANDRA-8316> "Did > not get positive replies from all endpoints" error on incremental repair > CASSANDRA-8580 <https://issues.apache.org/jira/browse/CASSANDRA-8580> > AssertionErrors > after activating unchecked_tombstone_compaction with leveled compaction > CASSANDRA-8458 <https://issues.apache.org/jira/browse/CASSANDRA-8458> > Don't > give out positions in an sstable beyond its first/last tokens > > Can you capture the elements of what we need and put it under > CASSANDRA-9012. Maybe a ticket for testing repair under load, a ticket for > switching compaction strategies and what the test scenarios for that would > be, and when you say configurations what kind of configurations are you > thinking of? > will add subtickets to #9012 > > CASSANDRA-8525 <https://issues.apache.org/jira/browse/CASSANDRA-8525> > Bloom > Filter truePositive counter not updated on key cache hit > > I think for JMX we only need to test that the access path delivers the > value. Knowing we had to test for the value was I think an original > implementer and reviewer issue. There was a metric exposed by the unit so > we needed a test that shows the metric has a correct value. > > CASSANDRA-8532 <https://issues.apache.org/jira/browse/CASSANDRA-8532> Fix > calculation of expected write size during compaction > https://issues.apache.org/jira/browse/CASSANDRA-8562 Fix checking > available disk > space before compaction starts > > Great. Linked 9154 to 9012 (Triage missing tests) > > CASSANDRA-8635 <https://issues.apache.org/jira/browse/CASSANDRA-8635> STCS > cold sstable omission does not handle overwrites without reads > > Can you create a ticket for this then? We should emit this workload pattern > and then validate after that utilization is as expected. > > Alternatively this could be caught as a performance regression? It's > starting to seem like some regressions could be caught as performance > regressions. > Yes this would definitely be caught in a performance test, if the workload was correct (ie, very few reads, many writes) /Marcus
