A command line tool to generate massive random Java applications
The command line tool you’ve been waiting for. Or not. After all, it’s pretty esoteric. Either way, it’s pretty useful to some, and an amusing utility to others. Bullshifier is an internal OverOps tool developed by David Levanon and Hodaya Gamliel. It’s used in order to test some of our monitoring capabilities over ridiculously large code bases, with transactions that go thousands of calls deep, over thousands of classes, and end up with exceptions.
Let’s dig into how to use it and why we built it.
OverOps shows developers where, when, and why code breaks in production. Whenever there’s a logged error, warning, or exception, it shows you the complete source code and variable state across the entire call stack at the moment of error.
It’s built for production, and requires a low overhead that never goes over 3% in terms of CPU and memory. As such, as part of our process, we needed to test it with some extreme edge cases – and this is where Bullshifier comes in:
- Generates massive projects with tons of code and logging
- Runs across methods with deep call stacks
- Throws exceptions caused by random variable state
- Groovy installed
- Java installed
- Download, unzip, and you’re ready to go
- ./gradlew run (Default parameters, generates one jar with 10 classes)
- cd output && gradle fatJar to build the generated project
- java -cp output/build/libs/tester.jar helpers.Main to run it
Or, you can simply run ./scripts/small.sh, or ./scripts/big.sh, with preconfigured run settings.
- -Poutput-directory (Relative path to output directory)
- -Poutput-classes (number of classes to generate)
- -Psubprojects (number of jars to generate)
Keep in mind that generating over 500 classes will take quite some time. Our biggest run had 20,000 classes, but its better to keep this under 5,000.
Running sub projects
- /gradle build (get a WAR file)
- Go to bin
- A shell script is created per project, root will run them all
There are some additional options that give you fine grained control over the generated code, but might mess it up, use at your own risk:
- Low level config: src/main/groovy/generator/Config.groovy
- Higher level config is available in the output folder. There are more options to add logging, and fine tune the behavior of the application but it’s experimental at the moment.
If you’d like to learn more, feel free to reach out or ask us in the comments section for a deeper walkthrough. Default settings are no logs, and an exception on every 10th frame in the call stack.
Fun fact, at first, all those randomly generated class and variable names caused a lot of hits with reserved words. Even though they’re completely random, because of the huge amounts of generated code. So now it’s random minus reserved words 😛
Each generated method contains 4 sections:
- Variable definition, with random types, random names, and values.
- A section that throws exceptions, or prints to the log, according to the config settings for the rate of events. This also includes a “suicide” function that stops the execution of the program.
- Calls the next method.
- Code that never runs.
So.. what do you think? We reply to every comment.
Achieving Observability: How to Address the Unknown Unknowns in Your Application
Subscribe for Post Updates