I'm testing startup checks and expect them to fail in a certain scenario but
the test just exists because when a startup check fails, Cassandra calls
System.exit.
It is possible to create CassandraDaemon with "runManaged" constructor arg
which prevents System.exit and make the code throw Runtim
We can also ByteWeave System.exit away, or migrate it to some other method
invocation that e.g. throws an exception.
The simulator makes extensive use of byte weaving on top of the dtest api. It
should be landing soon, and we could repurpose some of its code for regular
dtests. Or we may want t
> It is also possible to install security manager which prevents System.exit.
> If so, should this be implemented globally for all the JVM dtests or
> individually for JVM dtests which need that? I'm asking because when
> System.exit is called unexpectedly, the test is not reported as failed - i
> should we let users enable the new uuid ids later when they are sure they
> will not downgrade in the future?
I strongly believe new features should be off by default and give a “good
enough” grace period before enabling by default (while still offering support
to disable). As long as this i
Yes, I implemented that as mentioned above - cassandra.yaml option,
disabled by default, description explaining the reason and consequences.
- - -- --- - -
Jacek Lewandowski
On Wed, Oct 27, 2021 at 3:58 PM David Capwell
wrote:
> > should we let users enable the new uu
Reading the CEP I don’t see any mention to the systems which access SSTables;
such as streaming (small callout to zero-copy-streaming with
ZeroCopyBigTableWriter) and repair. If you are abstracting out BigTableReader
then you are not dealing with the implementation assumptions that users of
SS
