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.bacho...@oracle.com> wrote:
> On 1.5.2015 21:55, Martin Buchholz wrote:
>
>>
>>
>> On Thu, Apr 30, 2015 at 11:27 AM, Jaroslav Bachorik
>> <jaroslav.bacho...@oracle.com <mailto:jaroslav.bacho...@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-
>
