On 02.04.2011 01:20, Konstantin Kolinko wrote:
2011/4/1 Konstantin Kolinko<knst.koli...@gmail.com>:
In the recent run:
[junit] Apr 1, 2011 9:53:27 PM
org.apache.catalina.util.SessionIdGenerator createSecureRandom
[junit] INFO: Creation of SecureRandom instance fo
[junit] r session ID generation using [SHA1PRNG] took [69,367]
milliseconds.
and so on in the next runs.
That explains the slowness. It is good that we have this logging now.
I know there was some related discussion on the users list, but just in
case it didn't become clear from that.
There is a bug in the Oracle JVM. Initialization of random number
generation on Linux can block for a long time, because even if
configured for using /dev/urandom it will use /dev/random. 1.6.0_24 even
seems to be preconfigured for using /dev/urandom on Linux, but it dows
not work due to an implementation bug.
Workaround: You can still use the system property "java.security.egd" to
switch to /dev/urandom, but you have to use a value that is semantically
equivalent to /dev/urandom but not stringwise identical. So instead of
the value proposed usually:
-Djava.security.egd=file:/dev/urandom
You can use
-Djava.security.egd=file:/dev//urandom
or
-Djava.security.egd=file:/dev/./urandom
Looking at the JVM sources one can see the reason. On Linux, when
configuring exactly for /dev/random or /dev/urandom, the JVM prefers to
use a so-called native random number generator. It initializes the
native generator with the default constructor, that always uses /dev/random.
When switching from file:/dev/urandom to something equivalent but not
identical, you finally get what you were looking for.
Oracle thinks it is not a bug, but from the bug report comments it seems
they haven’t actually looked at their code and are still only arguing
about /dev/urandom not being secure.
Regards,
Rainer
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
For additional commands, e-mail: dev-h...@tomcat.apache.org
