[PATCH] Review Request - Test bug: 6948101 java/rmi/transport/pinLastArguments/PinLastArguments.java failing intermittently

[Eric Wang]

Hi Stuart and David,

Thanks for the suggestion about the timeout. so there are three ways to 
handle the timeout.

1. Add comment to explain that test failed due to default timeout
2. Specify the the timeout option
3. Timeout programly

Is it ok for you that i'd like to choose the second way "explict 
timeout" as the test looks simply and lucid?

Regards,
Eric

On 2012/7/3 10:38, David Holmes wrote:
> On 3/07/2012 7:08 AM, Stuart Marks wrote:
>> On 7/1/12 5:39 PM, David Holmes wrote:
>>>> Now, how can the test fail? If ref is never cleared, the while loop 
>>>> will
>>>> never terminate, and we rely on jtreg to timeout and kill this 
>>>> test. It
>>>> would be good to have a brief comment above the while loop that 
>>>> explains
>>>> this.
>>>
>>> Agreed. Something like
>>>
>>> // Might require multiple calls to System.gc() for weak-references
>>> processing
>>> to be complete.
>>> // If the weak-reference is not cleared as expected we will hang here
>>> // until timed out by the test harness
>>>
>>> Though now I write that I'm unhappy that this will only behave nicely
>>> if run
>>> from jtreg. We do use explicit timeouts in other tests.
>>
>> So, are you unhappy enough that we should ask Eric to add an explicit
>> timeout?
>
> No. But I'm not the authoritive voice in this area :)
>
>> I don't think it would be that difficult. Perhaps a technique like the
>> following would suffice. Get System.currentTimeMillis() before the loop,
>> and call it again each time through the loop, and fail if the difference
>> is greater than the timeout (e.g., 60 sec). Doesn't involve other
>> threads or even Timer/TimerTask.
>
> Or simply limit the number of loops so that N*sleepTime = timeout. 
> This then requires adding back the check for null outside the loop.
>
>> On the other hand if one is running this test directly instead of
>> through jtreg, one can just ^C it if it's taking an unexpectedly long 
>> time.
>
> True.
>
> David
> -----
>
>
>> s'marks