tomcat-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Rainer Jung <>
Subject Re: [GUMP@vmgump]: Project tomcat-trunk-test (in module tomcat-trunk) failed
Date Mon, 04 Apr 2011 09:59:37 GMT
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<>:
>>> 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 ""
>> 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="" 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]
> [2]



To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message