Codereview request: 8050115 javax/management/monitor/GaugeMonitorDeadlockTest.java fails intermittently
Daniel Fuchs
daniel.fuchs at oracle.com
Wed Sep 17 09:19:04 UTC 2014
On 9/17/14 10:55 AM, shanliang wrote:
> David Holmes wrote:
>> On 17/09/2014 7:01 AM, shanliang wrote:
>>> David Holmes wrote:
>>>> Hi Shanliang,
>>>>
>>>> On 16/09/2014 7:12 PM, shanliang wrote:
>>>>> Hi,
>>>>>
>>>>> Please review the following fix:
>>>>
>>>> I don't see any functional change. You seem to have replaced a
>>>> built-in timeout with the externally applied test harness timeout.
>>> Yes no functional change here, we thought that the test needed more time
>>> to wait a change if a testing VM or machine was really slow, the test
>>> harness timeout was the maximum time we could give the test.
>>
>> Do we have confidence that the harness timeout is sufficient to handle
>> the intermittent failures?
> Really a good question :)
>
> Here is new version:
> http://cr.openjdk.java.net/~sjiang/JDK-8050115/01/
>
> I added a deadlocked check in every 1 second, hope to get more info in
> case of failure.
The following comment seems to imply that this check is not
very useful:
112 // This won't show up as a deadlock in CTRL-\ or in
113 // ThreadMXBean.findDeadlockedThreads(), because they
don't
114 // see that thread A is waiting for thread B
(B.join()), and
115 // thread B is waiting for a lock held by thread A
best regards,
-- daniel
>
> I changed also the sleep time to 100ms, 10ms seems too short as Daniel
> pointed out.
>
> Thanks,
> Shanliang
>>
>> Thanks,
>> David
>>
>>
>>>>
>>>> Style nit: add a space after 'while' -> while (cond) {
>>> OK, I will do it before pushing.
>>>
>>> Thanks,
>>> Shanliang
>>>>
>>>> David
>>>> -----
>>>>
>>>>> bug: https://bugs.openjdk.java.net/browse/JDK-8050115
>>>>> webrev: http://cr.openjdk.java.net/~sjiang/JDK-8050115/00/
>>>>>
>>>>> Thanks,
>>>>> Shanliang
>>>
>
More information about the serviceability-dev
mailing list