tomcat-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Konstantin Kolinko <knst.koli...@gmail.com>
Subject Re: [GUMP@vmgump]: Project tomcat-trunk-test (in module tomcat-trunk) failed
Date Thu, 07 Apr 2011 04:48:16 GMT
2011/4/4 Rainer Jung <rainer.jung@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.kolinko@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-unsubscribe@tomcat.apache.org
For additional commands, e-mail: dev-help@tomcat.apache.org


Mime
View raw message