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

[Sean Mullan]

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.Bateman at 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
>