Harmony
  1. Harmony
  2. HARMONY-2338

[classlib][luni] tests.api.java.net.ServerSocketTest failed intermittently

    Details

    • Type: Bug Bug
    • Status: Closed
    • Priority: Major Major
    • Resolution: Fixed
    • Affects Version/s: None
    • Fix Version/s: None
    • Component/s: Classlib
    • Labels:
      None
    • Environment:
      SuSE 9 ia32 multi-processor
    • Patch Info:
      Patch Available

      Description

      The test failed 2 times from 162 on DRLVM r479662.

        Issue Links

          Activity

          Hide
          Alexei Fedotov added a comment -

          ...................F......
          Time: 5.124
          There was 1 failure:
          1) test_setReuseAddressZ(tests.api.java.net.ServerSocketTest)junit.framework.AssertionFailedError: Exception during test : The address is not available
          at tests.api.java.net.SocketTestCase.handleException(SocketTestCase.java:116)
          at tests.api.java.net.ServerSocketTest.test_setReuseAddressZ(ServerSocketTest.java:819)
          at java.lang.reflect.VMReflection.invokeMethod(Native Method)

          FAILURES!!!
          Tests run: 25, Failures: 1, Errors: 0

          Show
          Alexei Fedotov added a comment - ...................F...... Time: 5.124 There was 1 failure: 1) test_setReuseAddressZ(tests.api.java.net.ServerSocketTest)junit.framework.AssertionFailedError: Exception during test : The address is not available at tests.api.java.net.SocketTestCase.handleException(SocketTestCase.java:116) at tests.api.java.net.ServerSocketTest.test_setReuseAddressZ(ServerSocketTest.java:819) at java.lang.reflect.VMReflection.invokeMethod(Native Method) FAILURES!!! Tests run: 25, Failures: 1, Errors: 0
          Hide
          Vasily Zakharov added a comment -

          I've investigated this issue a bit.

          Most test cases use tests.support.Support_PortManager.getNextPort() method to generate the "random" port numbers from 6000 to 65535. However, some ports are occupied by other applications, and when getNextPort() provides some test case with an occupied port number, that test case fails.

          Possible ways to resolve the problem are:

          1. "Check" each port number for availability at the start of each test case.

          1.1. For example, by creating ServerSocket with some "well known" parameters and making sure no exception occurs.

          1.2. Another way may be creating a Socket to that port and making sure the connection fails.

          2. Change the port numbers range to exclude the occupied ports. Not a good solution, of course.

          3. Use fixed port numbers instead of "random" ones. This is more reliable, but also not very good, and also limits the "coverage".

          4. Do not treat a BindException as a test fail, and try another port instead, may be 3 times or so.

          I'm not a java.net developer, so I'm not sure which way is good and which is not, so suggestions would be appreciated.

          Show
          Vasily Zakharov added a comment - I've investigated this issue a bit. Most test cases use tests.support.Support_PortManager.getNextPort() method to generate the "random" port numbers from 6000 to 65535. However, some ports are occupied by other applications, and when getNextPort() provides some test case with an occupied port number, that test case fails. Possible ways to resolve the problem are: 1. "Check" each port number for availability at the start of each test case. 1.1. For example, by creating ServerSocket with some "well known" parameters and making sure no exception occurs. 1.2. Another way may be creating a Socket to that port and making sure the connection fails. 2. Change the port numbers range to exclude the occupied ports. Not a good solution, of course. 3. Use fixed port numbers instead of "random" ones. This is more reliable, but also not very good, and also limits the "coverage". 4. Do not treat a BindException as a test fail, and try another port instead, may be 3 times or so. I'm not a java.net developer, so I'm not sure which way is good and which is not, so suggestions would be appreciated.
          Hide
          Vasily Zakharov added a comment -

          Creating a workaround (see 1.2. above) resolved most issues. However, test_setReuseAddressZ() continues to fail from time to time.

          Additional workaround was then used in tests.support.Support_PortManager, setting lastAssignedPort to 6000 instead of somewhatRandomPort(). This fixes the port numbers used on each test run, and this makes test_setReuseAddressZ() to fail almost every time. Investigating further.

          Show
          Vasily Zakharov added a comment - Creating a workaround (see 1.2. above) resolved most issues. However, test_setReuseAddressZ() continues to fail from time to time. Additional workaround was then used in tests.support.Support_PortManager, setting lastAssignedPort to 6000 instead of somewhatRandomPort(). This fixes the port numbers used on each test run, and this makes test_setReuseAddressZ() to fail almost every time. Investigating further.
          Hide
          Vasily Zakharov added a comment -

          In fact, if starting lastAssignedPort is fixed, test_setReuseAddressZ() runs ok the first time and fails all the next times.
          The reason for that is trivial: at the test case beginning, setReuseAddress(false) is called and the test case breaks due to a port was open by it's own previous call.
          If lastAssignedPort is not fixed, the effect would occur rarely, but would still be possible.
          The test passes on Windows as Windows doesn't handle setReuseAddress(false) properly.

          Summary: current test design assumes the ports returned by tests.support.Support_PortManager.getNextPort() are free (this is actual for all test cases), and also are not in TIME_WAIT state (this is only actual for test_setReuseAddressZ test case). Either this should somehow be guaranteed, or the test design should be altered essentially.

          Show
          Vasily Zakharov added a comment - In fact, if starting lastAssignedPort is fixed, test_setReuseAddressZ() runs ok the first time and fails all the next times. The reason for that is trivial: at the test case beginning, setReuseAddress(false) is called and the test case breaks due to a port was open by it's own previous call. If lastAssignedPort is not fixed, the effect would occur rarely, but would still be possible. The test passes on Windows as Windows doesn't handle setReuseAddress(false) properly. Summary: current test design assumes the ports returned by tests.support.Support_PortManager.getNextPort() are free (this is actual for all test cases), and also are not in TIME_WAIT state (this is only actual for test_setReuseAddressZ test case). Either this should somehow be guaranteed, or the test design should be altered essentially.
          Show
          Alexei Fedotov added a comment - Here is a related thread on dev@harmony http://mail-archives.apache.org/mod_mbox/harmony-dev/200612.mbox/%3c4d0b24970612060159n4e1efc9cxf3e85868878e31a3@mail.gmail.com%3e
          Hide
          Mikhail Markov added a comment -

          I've implemented the following scheme
          1) try to use of ServerSocket(0) to find non-busy port (i did not notice any objections agains using ServerSocket )
          2) If the 1-st step fails at least once (meaning that something wrong with ServerSocket) then use previous unsafe method.
          The attached patch modifies Support_PortManager class so all tests using it will utilize this scheme.
          Hope this solves the issue.

          Show
          Mikhail Markov added a comment - I've implemented the following scheme 1) try to use of ServerSocket(0) to find non-busy port (i did not notice any objections agains using ServerSocket ) 2) If the 1-st step fails at least once (meaning that something wrong with ServerSocket) then use previous unsafe method. The attached patch modifies Support_PortManager class so all tests using it will utilize this scheme. Hope this solves the issue.
          Hide
          Alexei Zakharov added a comment -

          Mikhail, as far as I understand from the above-mentioned discussion the final decision was to reserve some fixed ports (or port segments) in the unused port space: http://mail-archives.apache.org/mod_mbox/harmony-dev/200612.mbox/%3c3D8E84095C6A524A985B787423094E40872833@mssmsx411%3e
          So we probably need a solution that takes fixed port number(s) from system property or smth. like it. Did I miss something?

          Show
          Alexei Zakharov added a comment - Mikhail, as far as I understand from the above-mentioned discussion the final decision was to reserve some fixed ports (or port segments) in the unused port space: http://mail-archives.apache.org/mod_mbox/harmony-dev/200612.mbox/%3c3D8E84095C6A524A985B787423094E40872833@mssmsx411%3e So we probably need a solution that takes fixed port number(s) from system property or smth. like it. Did I miss something?
          Hide
          Mikhail Markov added a comment -

          I've resumed the discussion there - I'll update the patch if it's decided to use fixed ports after my proposal.

          Show
          Mikhail Markov added a comment - I've resumed the discussion there - I'll update the patch if it's decided to use fixed ports after my proposal.
          Hide
          Mikhail Markov added a comment -

          Alexei, we've agreed with Andrew Zhang to use my proposed solution for now (see http://mail-archives.apache.org/mod_mbox/harmony-dev/200612.mbox/%3c51abf0750612260906p2a885526wf0afa63b12c87f1e@mail.gmail.com%3e).
          Could you please integrate the patch? Thanks!

          Show
          Mikhail Markov added a comment - Alexei, we've agreed with Andrew Zhang to use my proposed solution for now (see http://mail-archives.apache.org/mod_mbox/harmony-dev/200612.mbox/%3c51abf0750612260906p2a885526wf0afa63b12c87f1e@mail.gmail.com%3e ). Could you please integrate the patch? Thanks!
          Hide
          Alexei Zakharov added a comment -

          Committed at the revision r497001. Thanks everyone. Mikhail, please verify.

          Show
          Alexei Zakharov added a comment - Committed at the revision r497001. Thanks everyone. Mikhail, please verify.
          Hide
          Mikhail Markov added a comment -

          Thanks, Alexei! Everything is fine.

          Show
          Mikhail Markov added a comment - Thanks, Alexei! Everything is fine.
          Hide
          Mikhail Markov added a comment -

          Alexei, could you please also check HARMONY-2339 and HARMONY-2821 - exceptions seems to me the same as the one for this bug.

          Show
          Mikhail Markov added a comment - Alexei, could you please also check HARMONY-2339 and HARMONY-2821 - exceptions seems to me the same as the one for this bug.
          Hide
          Alexei Zakharov added a comment -

          verified

          Show
          Alexei Zakharov added a comment - verified

            People

            • Assignee:
              Alexei Zakharov
              Reporter:
              Alexei Fedotov
            • Votes:
              0 Vote for this issue
              Watchers:
              1 Start watching this issue

              Dates

              • Created:
                Updated:
                Resolved:

                Development