[prev in list] [next in list] [prev in thread] [next in thread] 

List:       openjdk-serviceability-dev
Subject:    Re: RFR: JDK-8130084: javax/management/MBeanServer/NotifDeadlockTest.java timed out
From:       Ujwal Vangapally <ujwal.vangapally () oracle ! com>
Date:       2017-04-24 8:39:56
Message-ID: 72bf40e7-61d8-e541-da21-69036d1c94dc () oracle ! com
[Download RAW message or body]

Daniel, David

Thanks for the review :-)

-Ujwal


On 4/18/2017 5:39 PM, David Holmes wrote:
> Hi Daniel,
>
> On 18/04/2017 8:39 PM, Daniel Fuchs wrote:
>> On 18/04/2017 05:20, David Holmes wrote:
>>> Hi Ujwal,
>>>
>>> On 14/04/2017 4:25 PM, Ujwal Vangapally wrote:
>>>> Please review this small change
>>>>
>>>> https://bugs.openjdk.java.net/browse/JDK-8130084
>>>>
>>>> Webrev:
>>>> http://cr.openjdk.java.net/~uvangapally/webrev/2017/8130084/webrev.00/
>>>
>>> I agree with Daniel this makes the test less susceptible to spurious
>>> timeouts and will instead only be timed-out by the test harness.
>>
>> Hi David,
>>
>>> One additional comment though is that it now seems to serve no point to
>>> create a separate thread to do the work. ??
>>
>> AFAICS the test attempts to tease the JMX notification logic to
>> produce a deadlock. I believe we would have to go back to the original
>> bug description and make a careful analysis of the original issue
>> to assert whether or not creating that thread was integral to
>> the issue being tested (or if it was just a way to not wait
>> infinitely).
>
> You are absolutely right - it does need the second thread to ensure 
> there is no deadlock.
>
> Thanks,
> David
> -----
>
>> So all in all I think I'm more comfortable with not removing that
>> thread and leaving the fix as it is ;-)
>>
>> best regards,
>>
>> -- daniel
>>
>>>
>>> Thanks,
>>> David
>>>
>>

[prev in list] [next in list] [prev in thread] [next in thread]