RFR 8078143: java/lang/management/ThreadMXBean/AllThreadIds.java fails intermittently

[Martin Buchholz]

toString() should never return null, I think.

  52         @Override  53         public String toString() {  54
       T resolved = val.get();  55             return resolved != null
? resolved.toString() : null;  56         }


I expected methods like waitForCondition to include a timeout with
failure.  I like 10 seconds, being large enough to never be hit spuriously
in tests.

Why not
() -> (long) mbean.getThreadCount(),

 169             ()->{ 170                 curLiveThreadCount =
mbean.getThreadCount(); 171                 return
(long)curLiveThreadCount; 172             },


I worry that
mbean.getThreadCount()
is hard to test since the "system" may spin up and shut down utility
threads at any time.

On Wed, May 13, 2015 at 4:46 AM, Jaroslav Bachorik <
jaroslav.bachorik at oracle.com> wrote:

> On 1.5.2015 21:55, Martin Buchholz wrote:
>
>>
>>
>> On Thu, Apr 30, 2015 at 11:27 AM, Jaroslav Bachorik
>> <jaroslav.bachorik at oracle.com <mailto:jaroslav.bachorik at oracle.com>>
>> wrote:
>>
>>     On 30.4.2015 19:18, Martin Buchholz wrote:
>>
>>         Tests that sleep can almost always be better written some other
>> way.
>>         In this case, I would prefer busy-waiting with timeout until the
>>         expected condition becomes true.
>>
>>
>>     The thing is that in case of a real issue with the thread counters we
>>     a/ would be busy-waiting till the test times out (using an arbitrary
>>     delay is also problematic due to different performance of different
>>     machines running with different configurations)
>>
>>
>> Far less problematic (performance-wise and reliability-wise) than the
>> fixed sleep.
>>
>>     b/ would get a rather confusing message about the test timing out at
>>     the end
>>
>>
>> You can easily improve the error message.
>>
>
> Well, not that easily. It is not possible to get a notification when JTREG
> decides to timeout the test. So you will get the standard JTREG message and
> that's all.
>
> I was able to modify the test to wait for a given condition and provide
> useful messages in case of mismatch and retry. For the price of an
> increased complexity. On the other hand, the test should be much more
> resilient to timing errors caused by slow setups.
>
> Updated webrev: http://cr.openjdk.java.net/~jbachorik/8078143/webrev.01
>
> Thanks,
>
> -JB-
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.openjdk.java.net/pipermail/serviceability-dev/attachments/20150513/79d47e1d/attachment.html>