2011/4/4 Rainer Jung <rainer.j...@kippdata.de>: > 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 >
With my changes to our build.xml this problem is now fixed. https://svn.apache.org/viewvc?view=revision&revision=1088467 The last Gump run for tomcat-trunk-test was successful, BIO + NIO tests completed in 21 mins 16 secs Regarding tomcat-trunk-validate, the current status is http://marc.info/?l=gump&m=130189110920329&w=2 My plan is to apply the workaround suggested by Stefan in that thread. I tried an alternative way, but that failed as well as before. Best regards, Konstantin Kolinko --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
