RFR 8210736: jdk/javax/xml/crypto/dsig/GenerationTests.java slow on linux

Alan Bateman Alan.Bateman at oracle.com
Fri Sep 14 12:14:56 UTC 2018


On 14/09/2018 03:40, Weijun Wang wrote:
> The test runs very slow on Linux and turns out reading from the embedded HTTP server is the bottleneck. Here is the fix:
>
>
> diff --git a/test/jdk/javax/xml/crypto/dsig/GenerationTests.java b/test/jdk/javax/xml/crypto/dsig/GenerationTests.java
> --- a/test/jdk/javax/xml/crypto/dsig/GenerationTests.java
> +++ b/test/jdk/javax/xml/crypto/dsig/GenerationTests.java
> @@ -24,7 +24,7 @@
>   /**
>    * @test
>    * @bug 4635230 6283345 6303830 6824440 6867348 7094155 8038184 8038349 8046949
> - *      8046724 8079693 8177334 8205507
> + *      8046724 8079693 8177334 8205507 8210736
>    * @summary Basic unit tests for generating XML Signatures with JSR 105
>    * @modules java.base/sun.security.util
>    *          java.base/sun.security.x509
> @@ -32,7 +32,7 @@
>    *          jdk.httpserver/com.sun.net.httpserver
>    * @compile -XDignore.symbol.file KeySelectors.java SignatureValidator.java
>    *     X509KeySelector.java GenerationTests.java
> - * @run main/othervm/timeout=300 GenerationTests
> + * @run main/othervm/timeout=300 -Dsun.net.httpserver.nodelay=true GenerationTests
>    * @author Sean Mullan
>    */
>
> I've run the test hundreds of times. With the system property set, the longest duration is 1m 58s; without it, the shortest is 15m 45s. That's a huge difference.
This property sets TCP_NODELAY which seems okay here (although it may be 
working around an issue that the HTTP server should address). In any 
case, the change looks okay and maybe /timeout=300 is not needed now.

-Alan




More information about the security-dev mailing list