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 to consider porting some dtests to the Simulator. From: Jacek Lewandowski <lewandowski.ja...@gmail.com> Date: Wednesday, 27 October 2021 at 11:01 To: dev@cassandra.apache.org <dev@cassandra.apache.org> Subject: [QUESTION] Should JVM dtests be resistant to System.exit called in the node thread? 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 RuntimeException instead (this is already implemented but the parameter needs to be explicitly passed to the constructor of CassandraDaemon, thus it is not the option without some refactoring). 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 - it is not reported at all (at least I saw that in IntelliJ). Thanks, Jacek --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@cassandra.apache.org For additional commands, e-mail: dev-h...@cassandra.apache.org
