Milan,
How do you check which tests are run? That's what I see in the
/test-support/jtreg_open_test_jdk_com_sun_jndi_dns_ConfigTests_TcpTimeout_java/com/sun/jndi/dns/ConfigTests/TcpTimeout.jtr
file after I have run the test locally on my machine:
----------messages:(5/233)----------
command: main TcpTimeout
reason: User specified action: run main TcpTimeout
Mode: othervm
Additional options from @modules: --add-modules java.base --add-exports
java.base/sun.security.util=ALL-UNNAMED
elapsed time (seconds): 1.751
...
----------messages:(5/313)----------
command: main TcpTimeout -Dcom.sun.jndi.dns.timeout.initial=5000
reason: User specified action: run main TcpTimeout
-Dcom.sun.jndi.dns.timeout.initial=5000
Mode: othervm
Additional options from @modules: --add-modules java.base --add-exports
java.base/sun.security.util=ALL-UNNAMED
elapsed time (seconds): 5.498
------------------------------------
Which is consistent with what I would expect given the timeout values.
The following output does not tell the full story, just the name of the test:
==============================
Test summary
==============================
TEST TOTAL PASS FAIL ERROR
jtreg:open/test/jdk/com/sun/jndi/dns/ConfigTests/TcpTimeout.java
1 1 0 0
==============================
TEST SUCCESS
-Pavel
> On 20 Sep 2019, at 15:42, Milan Mimica <[email protected]> wrote:
>
> Pavel,
>
> Here it is: http://cr.openjdk.java.net/~mmimica/8228580/webrev.04/
> I don't see the test is run twice when I execute "make test
> TEST=jtreg:test/jdk/com/sun/jndi/dns/ConfigTests/TcpTimeout.java". Am
> I missing something?
>
> On Thu, 19 Sep 2019 at 13:16, Pavel Rappo <[email protected]> wrote:
>>
>> Milan,
>>
>> This looks like a good start. Please consider
>>
>> 1. Setting TOLERANCE to 5 seconds
>> 2. Getting the second time mark immediately after the query returns (i.e. do
>> not waste your time in DNSTestUtils.debug(attrs))
>> 3. Making the test parametric instead of hardcoded for the
>> DEFAULT_DNS_CLIENT_TIMEOUT
>> 4. Running the test for at least 2 different values of the timeout, e.g.:
>>
>> * @run main TcpTimeout
>> * @run main TcpTimeout -Dcom.sun.jndi.dns.timeout.initial=5000
>>
>> As for you question, I'm not sure how we would be able to communicate the
>> fact that the response is truncated to the user. You could try to ask this
>> on the net-dev mailing list.
>>
>> -Pavel
>>
>>> On 18 Sep 2019, at 14:25, Milan Mimica <[email protected]> wrote:
>>>
>>> Hi Pavel
>>>
>>> Sure. Here is the incremental change:
>>> http://cr.openjdk.java.net/~mmimica/8228580/webrev.03/
>>>
>>> What actually bothers me from the beginning is the truncated response.
>>> The TXT attribute, a String, prints "A very popular h", but does not
>>> equals("A very popular h"), because of some stray bytes. I guess it's
>>> because of how DNS response parsing works. I can imagine how this
>>> could cause problems to users. I think, at least, we should have a way
>>> to tell the user that the response is truncated, and the payload is
>>> partial/invalid.
>>>
>>>
>>> On Tue, 17 Sep 2019 at 15:09, Pavel Rappo <[email protected]> wrote:
>>>>
>>>> Milan,
>>>>
>>>> While the CSR is being processed, could we maybe think of some additional
>>>> testing for that change? Otherwise, that test seems kind of anemic. It
>>>> makes sure that the query doesn't hang, but that's about it. It doesn't
>>>> check that the timeout is respected. I was wondering if you could propose
>>>> some way of testing that.
>>>>
>>>>> On 17 Sep 2019, at 09:55, Pavel Rappo <[email protected]> wrote:
>>>>>
>>>>> I have filed the CSR:
>>>>>
>>>>> https://bugs.openjdk.java.net/browse/JDK-8230965
>>>>>
>>>>>> On 13 Sep 2019, at 11:21, Pavel Rappo <[email protected]> wrote:
>>>>>>
>>>>>> Here's the latest webrev accumulating all the changes we've discussed so
>>>>>> far:
>>>>>>
>>>>>> http://cr.openjdk.java.net/~prappo/8228580/webrev.03/
>>>>>>
>>>>>> If people are okay with that I will proceed to creating a CSR.
>>>>
>>>
>>>
>>> --
>>> Milan Mimica
>>
>
>
> --
> Milan Mimica
