java.nio.BufferPoolMXBean getObjectName() occasionally returns null
Alan Bateman
Alan.Bateman at oracle.com
Tue Jul 19 06:30:52 PDT 2011
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
More information about the nio-dev
mailing list