extended.openjdk jdk_other com/sun/jndi/dns/ConfigTests/Timeout.java Failed: timeout in xxxxx ms, expected7750ms

com/sun/jndi/dns/ConfigTests/Timeout.java test failed with an exception similar to:
```
23:31:09 STDOUT:
23:31:09 Skip local DNS Server creation
23:31:09 Elapsed (ms): 14309
23:31:09 Expected (ms): 7750
23:31:09 STDERR:
23:31:09 java.lang.RuntimeException: Failed: timeout in 14309 ms, expected7750ms
23:31:09 at Timeout.handleException(Timeout.java:108)
23:31:09 at TestBase.launch(TestBase.java:84)
23:31:09 at TestBase.run(TestBase.java:50)
23:31:09 at Timeout.main(Timeout.java:61)
23:31:09 at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
23:31:09 at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
23:31:09 at java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
23:31:09 at java.base/java.lang.reflect.Method.invoke(Method.java:566)
23:31:09 at com.sun.javatest.regtest.agent.MainActionHelper$AgentVMRunnable.run(MainActionHelper.java:312)
23:31:09 at java.base/java.lang.Thread.run(Thread.java:861)
```
The test case (https://github.com/AdoptOpenJDK/openjdk-jdk11u/blob/master/test/jdk/com/sun/jndi/dns/ConfigTests/Timeout.java) expects to get a `SocketTimeoutException` and when it gets it compares the elapsed time against an expected time calculated from the socket API request timeout and the number of retries. The test fails because the elapsed time is deemed to be 'too long' with respect to the expected time.

The rule for 'too long' looks to be arbitrary. It may simply be that on the failing machine this is how long the API calls take.

I've only seen the test fail on `test-azure-win2016-x64-1`. Other tests fail on that machine with resource issues (e.g. insufficient resources to load jdk libraries), so maybe these timeouts are a side effect of a generally constrained machine.

To rerun the test on the failing machine: [Rerun in Grinder on same machine](https://ci.adoptopenjdk.net/job/Grinder/parambuild/?SDK_RESOURCE=nightly&TARGET=jdk_custom&TEST_FLAG=&UPSTREAM_TEST_JOB_NAME=&DOCKER_REQUIRED=false&ACTIVE_NODE_TIMEOUT=&VENDOR_TEST_DIRS=&EXTRA_DOCKER_ARGS=-v+%24%7BTEST_JDK_HOME%7D%3A%2Fopt%2Fjava%2Fopenjdk&TKG_OWNER_BRANCH=AdoptOpenJDK%3Amaster&TEST_PARALLELIZATION_PARAMS=&PLATFORM=x86-64_windows&GENERATE_JOBS=false&KEEP_REPORTDIR=true&PERSONAL_BUILD=true&ADOPTOPENJDK_REPO=https%3A%2F%2Fgithub.com%2FAdoptOpenJDK%2Fopenjdk-tests.git&LABEL=test-azure-win2016-x64-1&TEST_OPTIONS_PARAMS=&EXTRA_OPTIONS=&CUSTOMIZED_SDK_URL=&BUILD_IDENTIFIER=&NON_AQA_TEST_REPOS_HELP_TEXT=&ADOPTOPENJDK_BRANCH=master&LIGHT_WEIGHT_CHECKOUT=false&NON_AQA_TEST_REPOS=&ARTIFACTORY_SERVER=&TEST_REPO_PARAMS=&TEST_SELECTION_PARAMS=&TEST_PARALLELIZATION_PARAMS_HELP_TEXT=&JDK_SELECTION_PARAMS=&KEEP_WORKSPACE=false&USER_CREDENTIALS_ID=&JDK_VERSION=11&ITERATIONS=1&VENDOR_TEST_REPOS=&JDK_REPO=&PLATFORM_AND_MACHINE_HELP_TEXT=&OPENJ9_BRANCH=master&OPENJ9_SHA=&JCK_GIT_REPO=&VENDOR_TEST_BRANCHES=&OPENJ9_REPO=https%3A%2F%2Fgithub.com%2Feclipse%2Fopenj9.git&UPSTREAM_JOB_NAME=&PLATFORM_AND_MACHINE=&CUSTOM_TARGET=test%2Fjdk%2Fcom%2Fsun%2Fjndi%2Fdns%2FConfigTests%2FTimeout.java&VENDOR_TEST_SHAS=&JDK_BRANCH=&LABEL_ADDITION=&ARTIFACTORY_REPO=&ARTIFACTORY_ROOT_DIR=&POST_RUN_PARAMS_HELP_TEXT=&UPSTREAM_TEST_JOB_NUMBER=&DOCKERIMAGE_TAG=&JDK_SELECTION_PARAMS_HELP_TEXT=&JDK_IMPL=openj9&SSH_AGENT_CREDENTIAL=&AUTO_DETECT=true&TKG_SHA=&TEST_SELECTION_PARAMS_HELP_TEXT=&CUSTOMIZED_SDK_URL_CREDENTIAL_ID=&OPENJDK_SHA=&NUM_MACHINES=&BUILD_LIST=openjdk&UPSTREAM_JOB_NUMBER=&TEST_REPO_PARAMS_HELP_TEXT=&POST_RUN_PARAMS=&TIME_LIMIT=10&TEST_OPTIONS_PARAMS_HELP_TEXT=&JVM_OPTIONS=&PARALLEL=None)

---------------------------

Failed: timeout in xxxxx ms, expected7750ms

**Describe the bug**
A clear and concise description of what the bug is.

**To Reproduce**
Steps to reproduce the behavior (or Grinder rerun link):

**Expected behavior**
A clear and concise description of what you expected to happen.

**Screenshots**
If applicable, add screenshots to help explain your problem.

**Additional context**
Add any other context about the problem here.

Start with test/jdk/com/sun/jndi/dns/ConfigTests/Timeout.java and TestBase.java, then run the linked Grinder job on test-azure-win2016-x64-1. Compare the timeout calculation with the observed SocketTimeoutException delay and the machine's resource conditions. Done means the test no longer reports a spurious failure under the reproduced conditions.

Written by the indexing model from the issue text.