Uploaded image for project: 'JDK'
  1. JDK
  2. JDK-8143397

It looks like InetAddress.isReachable(timeout) works incorrectly

    Details

    • Subcomponent:
    • Introduced In Build:
      b03
    • Introduced In Version:
    • Resolved In Build:
      b97
    • OS:
      windows

      Backports

        Description

        Negative networking test
          HostReachability/ReachableHostNegativeTest
        has started to fail after fixes for JDK-8135305, JDK-8133015 were integrated.
        1. isReachable_8u72b02.log
          8 kB
          Maxim Soloviev
        2. isReachable_8u72b03.log
          6 kB
          Maxim Soloviev
        3. ReachableNegHostTest.java
          1 kB
          Maxim Soloviev
        4. TimeIsReachableTest.java
          2 kB
          Maxim Soloviev

          Issue Links

            Activity

            Hide
            msolovie Maxim Soloviev (Inactive) added a comment -
            I attached the test TimeIsReachableTest.java and 8u72b02 and 8u72b03 test results for different values of timeout.

            Show
            msolovie Maxim Soloviev (Inactive) added a comment - I attached the test TimeIsReachableTest.java and 8u72b02 and 8u72b03 test results for different values of timeout.
            Hide
            msheppar Mark Sheppard added a comment - - edited
            I think a possible contribution to this issue is that there is an "undocumented" minimum timeout for the API calls
            c.f.
            https://msdn.microsoft.com/en-us/library/windows/desktop/aa366050%28v=vs.85%29.aspx

            " Minimum timeout

                There appears to be an undocumented minimum timeout, below which unexpected behavior ensues! This minimum timeout is 1000 milliseconds. In Windows 7, setting it to any number between 1ms and 999ms results in these behaviors:


            1: The API still takes 1000ms to timeout if the ping gets lost, regardless of the requested timeout time.

            2: The API still receives pings with round-trip times of >100ms even with a requested timeout of 1ms.

            3: The API randomly returns instantly with error code 11010 (Error due to lack of resources) as if the ping timed-out, even with a requested timeout of 800ms. This is not supposed to happen. When it does this, the ping goes out (as seen by SmartSniff), but the reply is ignored since the API returns instantly with the error. "

            the minimum reliable timeout seems to be about 100ms
            Show
            msheppar Mark Sheppard added a comment - - edited I think a possible contribution to this issue is that there is an "undocumented" minimum timeout for the API calls c.f. https://msdn.microsoft.com/en-us/library/windows/desktop/aa366050%28v=vs.85%29.aspx " Minimum timeout     There appears to be an undocumented minimum timeout, below which unexpected behavior ensues! This minimum timeout is 1000 milliseconds. In Windows 7, setting it to any number between 1ms and 999ms results in these behaviors: 1: The API still takes 1000ms to timeout if the ping gets lost, regardless of the requested timeout time. 2: The API still receives pings with round-trip times of >100ms even with a requested timeout of 1ms. 3: The API randomly returns instantly with error code 11010 (Error due to lack of resources) as if the ping timed-out, even with a requested timeout of 800ms. This is not supposed to happen. When it does this, the ping goes out (as seen by SmartSniff), but the reply is ignored since the API returns instantly with the error. " the minimum reliable timeout seems to be about 100ms
            Hide
            afomin Alexander Fomin added a comment -
            This is a regression introduced in 8u72.
            What is a justification to defer it from the release?

            Probably whould better to revoke the fix that caused this regression?
            Show
            afomin Alexander Fomin added a comment - This is a regression introduced in 8u72. What is a justification to defer it from the release? Probably whould better to revoke the fix that caused this regression?
            Hide
            msolovie Maxim Soloviev (Inactive) added a comment -
            The most probable cause of a problem is JDK-8135305.
            Show
            msolovie Maxim Soloviev (Inactive) added a comment - The most probable cause of a problem is JDK-8135305.
            Hide
            hgupdate HG Updates added a comment -
            URL: http://hg.openjdk.java.net/jdk9/dev/jdk/rev/8418f5ee381d
            User: robm
            Date: 2015-12-09 15:16:23 +0000
            Show
            hgupdate HG Updates added a comment - URL: http://hg.openjdk.java.net/jdk9/dev/jdk/rev/8418f5ee381d User: robm Date: 2015-12-09 15:16:23 +0000
            Hide
            afomin Alexander Fomin added a comment -
            Core-libs nightly is OK. SQE OK to take the fix to CPU16_01
            Show
            afomin Alexander Fomin added a comment - Core-libs nightly is OK. SQE OK to take the fix to CPU16_01
            Hide
            hgupdate HG Updates added a comment -
            URL: http://hg.openjdk.java.net/jdk9/jdk9/jdk/rev/8418f5ee381d
            User: lana
            Date: 2015-12-16 19:10:55 +0000
            Show
            hgupdate HG Updates added a comment - URL: http://hg.openjdk.java.net/jdk9/jdk9/jdk/rev/8418f5ee381d User: lana Date: 2015-12-16 19:10:55 +0000

              People

              • Assignee:
                robm Robert Mckenna
                Reporter:
                msolovie Maxim Soloviev (Inactive)
              • Votes:
                0 Vote for this issue
                Watchers:
                9 Start watching this issue

                Dates

                • Due:
                  Created:
                  Updated:
                  Resolved: