Milan,
I satisfied myself by running the final version of the test some 8k times and
then pushed the change. Thanks for your patience and persistence.
I saw your question on the net-dev and nio-dev mailing lists. Thanks.
-Pavel
> On 24 Sep 2019, at 13:41, Milan Mimica wrote:
>
> Pavel,
>
>
> On 24 Sep 2019, at 13:41, Milan Mimica wrote:
>
> Pavel,
>
> Deal. Handling early returns too:
> http://cr.openjdk.java.net/~mmimica/8228580/webrev.05/
LGTM
-Chris
Pavel,
Deal. Handling early returns too:
http://cr.openjdk.java.net/~mmimica/8228580/webrev.05/
I will ask there about socket timeout semantics.
On Tue, 24 Sep 2019 at 12:51, Pavel Rappo wrote:
>
> Milan,
>
> Thanks for looking into this. I think you should ask a question on the
> expected
Milan,
Thanks for looking into this. I think you should ask a question on the expected
timing semantics and guarantees on net-dev (with maybe a cc to nio-dev).
As for our test. I agree with you that we should simply work a possibility of
early returns into the check.
...
/* The acceptable
Hi Pavel
Wow, I find this awesome. I don't have a Windows machine to play with,
but I think I may have found something.
The difference is how Java_sun_nio_ch_Net_poll is implemented. On unix
it uses poll(2), on Windows it uses select(2). Regarding timeouts,
poll() has "wait at least" semantics
Milan,
I'm observing the latest version (.04) of this test failing quite frequently
(4/100) on Windows (Windows Server 2012 R2 6.3 (amd64)) machines. The test
passes fine on macOS and Linux. Here's the typical output I see in the logs:
java.lang.RuntimeException: Query took 4997 ms. .
Got it. Thanks Pavel!
On Mon, 23 Sep 2019 at 13:37, Pavel Rappo wrote:
>
> 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
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:
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 wrote:
>
> Milan,
>
> This
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
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
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
I have filed the CSR:
https://bugs.openjdk.java.net/browse/JDK-8230965
> On 13 Sep 2019, at 11:21, Pavel Rappo 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
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.
> On 12 Sep 2019, at 20:06, Alan Bateman wrote:
>
> On 12/09/2019 12:41, Chris Hegarty wrote:
On 12/09/2019 12:41, Chris Hegarty wrote:
Here is an initial attempt to document these timeout/retry properties.
It’s effectively the wording lifted from the tech notes [1], with
“UDP” removed.
Thanks, this look and dropping the reference to "UDP" make sense.
One minor nit is that "are
I like the wording, it's concise. Thanks a lot for helping us with this, Chris!
Trivially, there's a typo: <2> instead of .
> On 12 Sep 2019, at 12:41, Chris Hegarty wrote:
>
> Here is an initial attempt to document these timeout/retry properties. It’s
> effectively the wording lifted from
Here is an initial attempt to document these timeout/retry properties. It’s
effectively the wording lifted from the tech notes [1], with “UDP” removed.
I deliberately avoided describing the implementation. It serves little purpose,
and in fact will greatly complicate the description, as well as
> On 11 Sep 2019, at 16:55, Alan Bateman wrote:
>
> I don't think the jndi-dns docs page is in the jdk repo.
Could you kindly point me to the location of the current jndi-dns docs page? I
can't seem to be able to even find anything related to that on the web. You
might want to try to use your
On 11/09/2019 16:16, Pavel Rappo wrote:
On 11 Sep 2019, at 16:10, Alan Bateman wrote:
I assume extending the timeout to TCP will require at least some minimal
updates to the descriptions.
Which descriptions do you have in mind? I cannot seem to find that text
anywhere in the current repo
> On 11 Sep 2019, at 16:10, Alan Bateman wrote:
>
> I assume extending the timeout to TCP will require at least some minimal
> updates to the descriptions.
Which descriptions do you have in mind? I cannot seem to find that text
anywhere in the current repo (jdk/jdk)
$ hg tip
changeset:
On 11/09/2019 15:56, Pavel Rappo wrote:
Sure, from
https://docs.oracle.com/javase/8/docs/technotes/guides/jndi/jndi-dns.html:
"Each lookup is initially performed using UDP. If the response is too long to be
returned in a UDP packet without being truncated, the lookup is repeated using TCP."
Sure, from
https://docs.oracle.com/javase/8/docs/technotes/guides/jndi/jndi-dns.html:
"Each lookup is initially performed using UDP. If the response is too long to
be returned in a UDP packet without being truncated, the lookup is repeated
using TCP."
and
On 11/09/2019 13:26, Pavel Rappo wrote:
I'm happy with the overall changeset. I have (once again) made some tiny
changes, you can see them here:
http://cr.openjdk.java.net/~prappo/8228580/webrev.02/
If you are okay with them, then we wait for a *R*eviewer. If the Reviewer(s)
are okay
Hi Pavel
Your changes look good to me.
On Wed, 11 Sep 2019 at 14:26, Pavel Rappo wrote:
>
> I'm happy with the overall changeset. I have (once again) made some tiny
> changes, you can see them here:
>
> http://cr.openjdk.java.net/~prappo/8228580/webrev.02/
>
> If you are okay with them,
Hi Florian
On Mon, 9 Sep 2019 at 15:04, Florian Weimer wrote:
>
> Ahh. The other option is to stick with one server and keep resending
> with larger and larger timeouts. Switching has the advantage that in
> case of a server problem, you get to a working server more quickly.
> Staying means
> > On 5 Sep 2019, at 16:02, Pavel Rappo wrote:
> >
> > I think we are almost there. What do you think of the following incremental
> > (i.e. on top of your latest webrev) change?
> >
> >http://cr.openjdk.java.net/~prappo/8228580/webrev.01/
> >
> > I fixed a couple of trivial typos and
Milan,
ping?
> On 5 Sep 2019, at 16:02, Pavel Rappo wrote:
>
> I think we are almost there. What do you think of the following incremental
> (i.e. on top of your latest webrev) change?
>
>http://cr.openjdk.java.net/~prappo/8228580/webrev.01/
>
> I fixed a couple of trivial typos and
* Milan Mimica:
> On Thu, 5 Sep 2019 at 18:59, Florian Weimer wrote:
>>
>> But I think in the UDP case, the client will retry. I think the total
>> timeout in the TCP case should equal the total timeout in the UDP case.
>> That's what I'm going to implement for glibc. The difference is that in
> On 6 Sep 2019, at 9:20 PM, Pavel Rappo wrote:
>
> Milan,
>
> In order to simulate the "Address already in use" scenario I did this:
>
>TcpDnsServer(int port) {
>try {
> * new ServerSocket(port, 0, InetAddress.getLoopbackAddress());
>serverSocket = new
On Thu, 5 Sep 2019 at 18:59, Florian Weimer wrote:
>
> But I think in the UDP case, the client will retry. I think the total
> timeout in the TCP case should equal the total timeout in the UDP case.
> That's what I'm going to implement for glibc. The difference is that in
> the TCP case, the
Milan,
In order to simulate the "Address already in use" scenario I did this:
TcpDnsServer(int port) {
try {
* new ServerSocket(port, 0, InetAddress.getLoopbackAddress());
serverSocket = new ServerSocket(port, 0,
InetAddress.getLoopbackAddress());
}
catch
* Milan Mimica:
> On Wed, 4 Sep 2019 at 20:32, Florian Weimer wrote:
>>
>> If you use the initial UDP timeout (one second, I think), the kernel
>> will not complete the TCP handshake if the initial SYN segment is lost
>> because the retransmit delay during the handshake is longer than that.
>
>
On Wed, 4 Sep 2019 at 20:32, Florian Weimer wrote:
>
> If you use the initial UDP timeout (one second, I think), the kernel
> will not complete the TCP handshake if the initial SYN segment is lost
> because the retransmit delay during the handshake is longer than that.
We could set a higher
I think we are almost there. What do you think of the following incremental
(i.e. on top of your latest webrev) change?
http://cr.openjdk.java.net/~prappo/8228580/webrev.01/
I fixed a couple of trivial typos and addressed the socket relinquishing issue.
Initializing a socket is not an
* Pavel Rappo:
>> On 4 Sep 2019, at 18:54, Florian Weimer wrote:
>>
>> You should use a larger timeout than the initial UDP timeout,
>> though.
>
> Could you elaborate on that?
If you use the initial UDP timeout (one second, I think), the kernel
will not complete the TCP handshake if the
> On 4 Sep 2019, at 18:54, Florian Weimer wrote:
>
> You should use a larger timeout than the initial UDP timeout,
> though.
Could you elaborate on that?
On 04/09/2019 18:52, Pavel Rappo wrote:
You are right, it definitely is a blocking operation. I missed it. I was
focused on
712 sock.setSoTimeout(timeoutLeft);
So I'd suggest we use explicit connect with timeout
java.net.Socket#connect(java.net.SocketAddress, int)
Are you
* Pavel Rappo:
>> On 4 Sep 2019, at 18:38, Florian Weimer wrote:
>>
>>
>>
>> Maybe I'm mistaken, but I think this:
>>
>> 692 Tcp(InetAddress server, int port, int timeout) throws IOException {
>> 693 sock = new Socket(server, port);
>> 694 sock.setTcpNoDelay(true);
>> 695
> On 4 Sep 2019, at 18:38, Florian Weimer wrote:
>
>
>
> Maybe I'm mistaken, but I think this:
>
> 692 Tcp(InetAddress server, int port, int timeout) throws IOException {
> 693 sock = new Socket(server, port);
> 694 sock.setTcpNoDelay(true);
> 695 out = new
* Pavel Rappo:
>> On 4 Sep 2019, at 17:35, Florian Weimer wrote:
>>
>> * Milan Mimica:
>>
>>> Continuing in a new thread with a RFR of my own:
>>> http://cr.openjdk.java.net/~mmimica/8228580/webrev.00/
>>
>> I would add a comment why there's no explicit TCP connection timeout in
>> the code.
> On 4 Sep 2019, at 17:35, Florian Weimer wrote:
>
> * Milan Mimica:
>
>> Continuing in a new thread with a RFR of my own:
>> http://cr.openjdk.java.net/~mmimica/8228580/webrev.00/
>
> I would add a comment why there's no explicit TCP connection timeout in
> the code. I assume you rely on the
> On 4 Sep 2019, at 13:26, Milan Mimica wrote:
>
> Hello
>
> Continuing in a new thread with a RFR of my own:
> http://cr.openjdk.java.net/~mmimica/8228580/webrev.00/
Here's the link to the previous discussion:
https://mail.openjdk.java.net/pipermail/core-libs-dev/2019-August/061918.html
* Milan Mimica:
> Continuing in a new thread with a RFR of my own:
> http://cr.openjdk.java.net/~mmimica/8228580/webrev.00/
I would add a comment why there's no explicit TCP connection timeout in
the code. I assume you rely on the TCP stack having its own timeout,
right? But I think it can be
Hello
Continuing in a new thread with a RFR of my own:
http://cr.openjdk.java.net/~mmimica/8228580/webrev.00/
It has the fixes applied from the first review of the patch.
The test was sporadically failing not because of missing
synchronization, but more likely because test was not waiting for
44 matches
Mail list logo
