java.nio.BufferPoolMXBean getObjectName() occasionally returns null (original) (raw)
Alan Bateman Alan.Bateman at oracle.com
Tue Jul 19 06:30:52 PDT 2011
- Previous message: java.nio.BufferPoolMXBean getObjectName() occasionally returns null
- Next message: java.nio.BufferPoolMXBean getObjectName() occasionally returns null
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
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
- Previous message: java.nio.BufferPoolMXBean getObjectName() occasionally returns null
- Next message: java.nio.BufferPoolMXBean getObjectName() occasionally returns null
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]