This looks great to me. Thanks for taking a look at it.
-Rob
On 12/09/19 12:36, Pavel Rappo wrote:
> > On 12 Sep 2019, at 03:54, Martin Buchholz <[email protected]> wrote:
> >
> > We're mostly in agreement.
>
> Good to hear and I agree!
>
> > On Wed, Sep 11, 2019 at 11:02 AM Pavel Rappo <[email protected]
> > <mailto:[email protected]>> wrote:
> >
> >
> > a. is not using any synchronization aid to make sure both threads wait for
> > each other (probably, the timeout value accommodates that)
> >
> > Thread.join is a synchronization aid! But there's no shortage of others.
> > We typically use a CountDownLatch to synchronize with another thread.
>
>
> I should have expressed myself more clear. I meant that the main thread and
> the thread created (and started) by `newStartedThread` (the test tread) do
> not wait for *each other* before they begin. This might be needed to make
> sure that they start at the same time (loosely speaking, of course). One
> might argue that the importance of this diminishes with the increase of the
> timeout that the main thread uses to wait for the test thread to die and the
> accuracy of measurements one agrees to tolerate.
>
> I'm seeing differences in our timeout-measuring routines as just a difference
> in tastes. Since a particular behavior here is not guaranteed anyway (as it's
> not a hard real-time system), all we can hope for in both cases is adequate
> timeout values and useful diagnostic output.
>
> Thanks for patiently staying with this thread for so long, Martin.
>
>
> ***
>
>
> Here's the updated version of the RFR based on the discussion so far:
>
> http://cr.openjdk.java.net/~prappo/8151678/webrev.02/
>
> For the reviewers. I totally forgot to explain why there's a multiplier of 2
> in some of the timeout calculations. The reason is the current behavior of
> InitialDirContext. The supplied connect timeout seems to be used twice. Once
> for making the actual TCP connection [1] and the second time while waiting
> for the server to respond to the BIND message [2]. Thus, the total time spent
> in that InitialDirContext ctor may be twice the expected. I believe it's a
> bug, but the bug that is not related to the issue in question. The current
> issue (8151678) is about intermittent failures of LdapTimeoutTest.
>
> -Pavel
>
> ---------------------------------------------------
> [1]
> http://hg.openjdk.java.net/jdk/jdk/file/79186d82463e/src/java.naming/share/classes/com/sun/jndi/ldap/Connection.java#l296,
>
> http://hg.openjdk.java.net/jdk/jdk/file/79186d82463e/src/java.naming/share/classes/com/sun/jndi/ldap/Connection.java#l320
> [2]
> http://hg.openjdk.java.net/jdk/jdk/file/79186d82463e/src/java.naming/share/classes/com/sun/jndi/ldap/LdapClient.java#l154,
>
> http://hg.openjdk.java.net/jdk/jdk/file/79186d82463e/src/java.naming/share/classes/com/sun/jndi/ldap/LdapClient.java#l365
>
