I recently had an issue with a Tomcat server taking very long to restart. It was bizarre because when the system was starting, the Tomcat server was taking about 20-30 seconds to start, but a subsequent Tomcat restart was taking 20-30 minutes.
The logs indicated that the following step was taking a lot of time:
INFO: Creation of SecureRandom instance for session ID generation using [SHA1PRNG] took [135172] milliseconds.

This lead to the Tomcat page with advice on faster startup. The problem was – Tomcat was using /dev/random as source of randomness, and when the entropy pool was exhausted, this device was blocking.
This explained why the problem was not manifesting right after system restart: because of the associated ‘noise’, there was a lot of entropy. But after the system was stable, the entropy pool was depleted.

The solution to this is to tell Tomcat to use the non-blocking /dev/urandom device instead of /dev/random:

When read, the /dev/random device will only return random bytes within the estimated number of bits of noise in the entropy pool.

A counterpart is /dev/urandom (“unlimited”) which reuses the internal pool to produce more pseudo-random bits. This means that the call will not block, but the output may contain less entropy than the corresponding read from /dev/random.
wikipedia

So, to make Tomcat use /dev/urandom you have 2 options:
1. As indicated in the Tomcat slow startup troubleshooting guide: Configure JRE to use a non-blocking entropy source by setting the following system property: Djava.security.egd=file:/dev/./urandom

2. Change the $JAVA_HOME/jre/lib/security/java.security settings file:
securerandom.source=file:/dev/urandom
instead of
securerandom.source=file:/dev/random

More about entropy

(more…)