java.nio.BufferPoolMXBean getObjectName() occasionally returns null (original) (raw)

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