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