code review request: 7122169: TcpTimeout fail for various reasons

[Weijun Wang]

On 12/20/2011 08:36 PM, Chris Hegarty wrote:
> I'm not familiar with the Windows VM time issue, but the other changes
> look fine to me.

In Windows VM, if you call Thread.sleep(10000) and measure the time 
elapsed, the difference of System.nanoTime() is precise always, but the 
difference of System.getCurrentMillies() can vary between 7 and 15 seconds.

Thanks
Max

>
> -Chris.
>
> On 12/20/11 10:22 AM, Weijun Wang wrote:
>> Hi Alan
>>
>> Do you have time to look at this fix?
>>
>> http://cr.openjdk.java.net/~weijun/7122169/webrev.01/
>>
>> I study the test again and find out it's not the same as those BadKdc*
>> tests, where the port number must obey a pattern (n-th server on n****).
>> So there is no need to assign one before the server socket is created.
>> Also, it seems simply creating a server socket can simulate a timeout,
>> no need to call accept() in a separate thread explicitly.
>>
>> I've tried the new test with JPRT and it runs fine.
>>
>> Thanks
>> Max
>>
>> -------- Original Message --------
>> *Change Request ID*: 7122169
>> *Synopsis*: TcpTimeout fail for various reasons
>>
>>
>> === *Description*
>> ============================================================
>> sun/security/krb5/auto/TcpTimeout.java
>>
>> The test fails intermittently on various systems for different reasons:
>>
>> 1. On all systems, it might fail if a port (random calculated) is
>> already opened by another process.
>>
>> 2. In some Windows virtual machines, the wall clock might go slower than
>> elapsed time. i.e. you can Thread.sleep() for 10 seconds but the change
>> in System.nanoTime() results shows a smaller value.
>>