java.nio.BufferPoolMXBean getObjectName() occasionally returns null
spoole at linux.vnet.ibm.com
Mon Jul 18 22:51:27 PDT 2011
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
> . 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.
>  http://hg.openjdk.java.net/jdk7/jdk7/jdk/rev/77dd50ba670b
> -------- Original Message --------
> Subject: java.nio.BufferPoolMXBean getObjectName() occasionally
> returns null
> Date: Mon, 18 Jul 2011 22:54:35 +0100
> From: Steve Poole <spoole at linux.vnet.ibm.com>
> To: nio-dev at openjdk.java.net
> Hi all, a small fix to a race condition that occurs under extreme and
> probably unrepresentative loading...
> sun.management.ManagementFactoryHelper provides the default
> implementation of java.nio.BufferPoolMXBean. The getObjectName() method
> uses a volatile field to store the object name. The name is filled in
> using a lazy sync method. Under high load a timing window is exposed in
> which the lazy sync succeeds but a caller still recieves null.
> The failing code is question is in
> The diff and testcase are attached.
> I don't know if the testcase is the right form - it creates a bunch of
> threads that drive the method to expose the problem and is fairly
> quick. I can show it happening on Ubuntu with JDK7 and with my local
> build of JDK8.
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the nio-dev