Faster random generator in Tomcat 7

I have the problem that Tomcat 7 is terribly slow on startup. I found this in the log file:

INFO: Creation of SecureRandom instance for session ID generation using [SHA1PRNG] took [12,367] milliseconds.

Security is important, sure, but not on my development machine. I could perfectly live with a standard fast random number generator. So I don't need this ridiculously slow SecureRandom implementation.

Question is: How can I disable it? Is searched for a solution but only found some deprecated info about a randomClass attribute which can be set to java.util.Random. I also found out that this attribute seems to be named secureRandomClass now in Tomca开发者_运维技巧t 7. I tried to set it to java.util.Random but this fails because Tomcat 7 casts the object to java.util.SecureRandom (And it's also documented that the specified class must extend java.util.SecureRandom, so it's no longer possible to use java.util.Random instead.)

So how can I get rid of this terribly slow random number generator startup so my development tomcat starts/restarts as fast as possible?

---

According to TomCat Wiki you can use non blocking entropy source:

"There is a way to configure JRE to use a non-blocking entropy source by setting the following system property: -Djava.security.egd=file:/dev/./urandom"

---

You might need to install Haveged on your server.

Tomcat is using SecureRandom to generate secure id on startup, and SecureRandom is using /dev/random or /dev/urandom to generate random number.

In some headless linux environment, /dev/random entropy pools might produce low quality of randomness and respond very slow on generating random number.

There is good article on explaining how Haveged can solve this problem.

how-to-setup-additional-entropy-for-cloud-servers-using-haveged

---

You probably need to patch Tomcat.

Though as a hack, you could always try extending java.util.SecureRandom with something that wraps a standard java.util.Random instance....... this would get past the cast problem at least.

One other thought.... could the slowdown be due to an exhausted entropy pool? You might want to try getting more entropy into the pool, this might make it go really fast.

---

just find securerandom.source=... from $JAVA_PATH/jre/lib/security/java.security file and change it as securerandom.source=file:/dev/./urandom

https://stackoverflow.com/a/26432537/450586

---

Old problem, but still around... In my case with an embedded Tomcat.

The -Djava.security.egd=file:/dev/./urandom solution did not work for me. So I googled until understanding the issue, but after a few tests with lsof it was apparent that the workaround doesn't work anymore. A quick look at the code confirmed that the current implementation ignores this system property.

The problem is Tomcat blocking on /dev/random, so I looked for ways to add entropy to the system and found this answer which worked great! In Debian as root:

apt-get install rng-tools
rngd -r /dev/urandom     # Run once during system start up

It may not be as super-duper-secure, but in my opinion is more that enough for session id generation.

By the way, I ended up using Jetty. Much quicker if you don't need all the features of Tomcat.

---

If your hardware supports it try using Java RdRand Utility available at: http://code.google.com/p/lizalab-rdrand-util/

Its based on Intel's RDRAND instruction and is about 10 times faster than SecureRandom and no bandwidth issues for large volume implementation.

Full disclosure, I'm the author of the utility.