java.nio.BufferPoolMXBean getObjectName() occasionally returns null

[Steve Poole]

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