java.nio.BufferPoolMXBean getObjectName() occasionally returns null

[Alan Bateman]

Steve Poole wrote:
> On 19/07/11 05:09, Alan Bateman wrote:
>> (cc'ing serviceability-dev)
>>
>> Thanks Steve, looks like this crept as part of some refactoring work 
>> [1]. Looks like PlatformLoggingMXBean has the same issue. I've 
>> created the following bug to track it:
>>
>> 7068328: BufferPoolMXBean and PlatformLoggingMXBean getObjectName may 
>> return null
>>
>> If no one take it in the next few days then I can take it and get it 
>> push to jdk8 (listing you are contributer). The test will need a bit 
>> of clean-up, re-formatting, and throwing an exception rather than 
>> calling System.exit for example.
>>
> Thanks Alan.  I wasn't sure of the testcase form to use for a 
> multithreaded problem - I will be curious to see how it ends up. 
The approach to have a pool of threads bang on the list returned by 
ManagementFactory.getPlatformMXBeans(BufferPoolMXBean.class) seems 
reasonable (I can't think of other ways that would easily demonstrate 
this bug). The main thing with tests such as this is they are highly 
robust and run quickly.

If you have cycles to improve the test then the main comment is that 
jtreg tests can't call System.exit (a shell test that runs the class 
could but we try to avoid shell tests for several reasons). One 
suggestion is to just add a static volatile boolean failed and set it to 
true if the object name is null or doesn't start with 
"java.nio:type=BufferPool,name=" (that would be more comprehensive that 
checking for the empty string). At the end of the test then throw a 
RuntimeException if failed is true.

I would also suggest using the Executors factory class rather than 
creating the ThreadPoolExecutor explicitly. You could invoke the 
shutdown method before awaitTermination. Another thing is that 1 second 
is likely to be insufficient when run on a busy machine. That isn't a 
correctness issue but subsequent j.l.management tests that run in the 
same VM might observe thread counts that they don't expect.

The final comment is just the indenting. We use 4 space indent but the 
attachment seem to be 8 (Windows tabs perhaps?).

-Alan.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mail.openjdk.java.net/pipermail/nio-dev/attachments/20110719/bf128061/attachment-0001.html