Improve unit tests performance (CASSANDRA-17427 --> trunk)

[jacek-lewandowski]

• Don't flush schema on every schema update in unit tests
• Use unix command to delete test data
• Shorten teardown
• Stable processor count presented by JMX on Jenkins, CircleCI and local

patch by @jacek-lewandowski reviewed by @michaelsembwever and @josh-mckenzie for CASSANDRA-17427

[michaelsembwever]

CI ci-cassandra: https://ci-cassandra.apache.org/job/Cassandra-devbranch/1834/

[jmckenzie-dev]

No really major issues on the review; looking solid.

[jmckenzie-dev]

Should this be a CassandraRelevantProperties?

[smiklosovic]

@josh-mckenzie great catch, yes, it definitely should be there. If we managed to have the second reviewer for CASSANDRA-17797 and we merged that work, this would fail the build :)

[jacek-lewandowski]

Quite interesting question. This is something to be used only in tests. Perhaps something overly contrived but maybe test properties should require something like cassandra.test property to be set in order to make them get assigned with a non-default value? (I mean, set cassandra.test to unlock those properties). Perhaps something for CASSANDRA-17797 @smiklosovic

[smiklosovic]

The patch we work on is gathering all properties, irrelevant what they are for, in one place. I understand these are just test properties but having them somewhere separately, for example, in test source, would mean that we would start to reference test class in the prod code. Right? Not good. Having test code referencing prod code where these test properties are is better.

I am not sure how to reply to your idea about cassandra.test. I think that in general it is good idea to have them with that prefix, yes. Otherwise we are not completely sure, at the first glance, if there is not any comment, what that property is actually used for / upon.

In the long run, we would like to have all test properties with such prefix (it is really messy right now) but the first task is to manage the current "chaos" with having them scattered across all the source code. As of now, nobody has a definitive answer what all properties we use ....

I think test properties with some value should be set as the very first thing in the test class? So the defaults would be overridden (if desirable) by a tester upon starting that test when this is final static. If the value of that property is meant to be changed during the test then this needs to be fixed on the code level to resolve that property dynamically as it is called.

[jacek-lewandowski]

I just meant to prevent setting those properties to some non-default values in production, that is, you can only override the defaults if some additional property like, -Dcassandra.test=true is set

[smiklosovic]

ah right ... @Mmuzaf this is an interesting point to take into account, we might deal with this later I guess.

[jmckenzie-dev]

In general there's a lot of whitespace removal in various files; I'm not sure why we have so many files w/trailing whitespace and we don't have anything in our style guide about it that I can see (link). So is without or with the way to go?

[jacek-lewandowski]

@josh-mckenzie I've applied your review comments, please have a look before I rebase and overwrite the branch

[smiklosovic]

@jacek-lewandowski this should be probably undeleted.

[jacek-lewandowski]

I'll make sure there is no such changes before committing/merging