java.nio.BufferPoolMXBean getObjectName() occasionally returns null
Steve Poole
spoole at linux.vnet.ibm.com
Thu Jul 21 11:43:24 PDT 2011
On 19/07/11 14:30, Alan Bateman wrote:
> 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 do have cycles but not for a week or so - I've been preping for two
trips back to back starting tomorrow - I'll keep this mail around to
remind me.
>
> 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?).
Actually its eclipse on Ubuntu - I will have to fix it: the tabbing, not
using Ubuntu or eclipse :-)
>
> -Alan.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mail.openjdk.java.net/pipermail/nio-dev/attachments/20110721/8fda13ba/attachment.html
More information about the nio-dev
mailing list