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.
