Just curious, but why is this not an issue on platforms other than
linux? Seems like we are working around a problem that maybe should be
fixed somewhere else ...
--Sean
On 9/14/18 10:33 AM, Weijun Wang wrote:
In my latest test that repeats 100 times, the slowest one runs for 208 seconds.
This test runs tens of thousands of signing and verifying and I'd like to keep
that timeout.
Thanks
Max
On Sep 14, 2018, at 8:14 PM, Alan Bateman <alan.bate...@oracle.com> wrote:
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
