RFR of 8194284: CheckRegisterInLog.java fails with java.lang.RuntimeException: CheckRegisterInLog got exception timeout 6480000ms out of range

Roger Riggs Roger.Riggs at Oracle.com
Thu Jan 18 14:33:45 UTC 2018


Hi Hamlin,

The base bug is that the timeoutFactor is being applied twice, once in 
the RMID constructor
and again in computeDeadline.  It is better to cleanup the 
implementation of the test library
than to fudge the values.  Either respect the timeouts passed in (remove 
the scaling from computeDeadline)
or consistently leave it to the lower level routines.  Pick 1.

Thanks, Roger


On 1/18/2018 1:59 AM, Hamlin Li wrote:
> Would you please review the following patch?
>
> bug: https://bugs.openjdk.java.net/browse/JDK-8194284
>
> webrev as below.
>
>
> Thank you
>
> -Hamlin
>
> ------------------------------------------------------------------------
>
> diff -r 0dec8c41170c test/jdk/java/rmi/testlibrary/TestLibrary.java
> --- a/test/jdk/java/rmi/testlibrary/TestLibrary.java    Wed Jan 17 
> 20:07:50 2018 -0800
> +++ b/test/jdk/java/rmi/testlibrary/TestLibrary.java    Thu Jan 18 
> 14:54:50 2018 +0800
> @@ -188,8 +188,12 @@
>      public static long computeDeadline(long timestamp, long timeout) {
>          final long MAX_TIMEOUT_MS = 3_600_000L;
>
> -        if (timeout < 0L || timeout > MAX_TIMEOUT_MS) {
> +        if (timeout < 0L) {
>              throw new IllegalArgumentException("timeout " + timeout + 
> "ms out of range");
> +        } else if (timeout > MAX_TIMEOUT_MS) {
> +            System.out.format("timeout value(%d) exceeds 
> MAX_TIMEOUT_MS(%d), "
> +                    + "use MAX_TIMEOUT_MS instead!%n", timeout, 
> MAX_TIMEOUT_MS);
> +            timeout = MAX_TIMEOUT_MS;
>          }
>
>          return timestamp + (long)(timeout * getTimeoutFactor());
>



More information about the jdk-dev mailing list