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