On 04.04.2011 11:34, Stefan Bodewig wrote:
On 2011-04-03, Rainer Jung wrote:
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.
vmgump is on 6b20 and I don't think there is anything more recent
available for Ubuntu 10.4 (unless we fiddle with package sources, I
guess).
Sorry, I didn't want to indicate it is a 1.6.0_24 problem only. It's
just that I checked the default only for 1.6.0_24. The issue is open at
Oracle for a longer.
But you seem to be correct this is a Linux issue. On FreeBSD[1] I see
140 ms.
It is also not strictly reproducable in the sense that fst startup means
you don't have the problem. You can check via open files or similar, if
/dev/random or /dev/urandom is being used. Even when /dev/random is used
due t the bug, sometimes there is enough entropy, sometimes not. I
usually run into the problem when trying to start two instances in
parallel. One starts up fast, the other blocks.
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.
You can set system properties via<sysproperty> inside the Gump
descriptor and if you use
<sysproperty name="ant.build.clonevm" value="true"/>
Ant will make sure any system property will be passed to a new Java VM
that is forked as well[2] (as long as forking uses Ant's mechanisms,
that is).
Good thing. Konstantin already added a jvmarg to our local build.xml, I
guess it will work in Gump but also when testing standalone.
It might be a nice default setting for the ASF gump, because more
projects might run into the same unpleasant issue.
Stefan
[1]
http://gump.zones.apache.org/gump/public/tomcat-trunk/tomcat-trunk-test/gump_work/build_tomcat-trunk_tomcat-trunk-test.txt
[2] http://ant.apache.org/manual/clonevm.html
Regards,
Rainer
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
For additional commands, e-mail: dev-h...@tomcat.apache.org
