Fooled by RandomNumberGenerator

We have a Java class that calls the SecureRandom to generate random numbers. We might have as well used Random, since it does not really matter for our use case to have that level of strict randomness, however, sonar-lint was not happy with Random and insisted on SecureRandom.

The unit test for the concerned class run fast when locally executed.

The CI flow triggers build in a docker container.

It so happened that the test cases in the build pipeline were taking hours to run.

First suspect was that the host on which the build runs does not have enough resources to run the build. But the top and free commands did not show anything alarming. The system had sufficient CPU, memory and swap.

Next step was to check the build logs and figure out where the delay was. It narrowed down to the area of test suite that was having this class in common - the one that used the SecureRandom

Upon taking jstack of the maven build process, it was almost always stuck at

NativePRNG’s readFully method

Which was waiting for entropy from /dev/random

Now, on local machine - there are enough interrupts, example mouse clicks etc that generate entropy. While in containerized environments, entropy take a while to generate and the call blocks until then. The tests were stuck waiting for the entropy.

When the volume mount from local host was given such as

-v /dev/urandom:/dev/random

The build then finished in seconds.