java.nio.BufferPoolMXBean getObjectName() occasionally returns null (original) (raw)
Steve Poole spoole at linux.vnet.ibm.com
Mon Jul 18 14:54:35 PDT 2011
- Previous message: Question about AsynchronousByteChannel.read()
- Next message: java.nio.BufferPoolMXBean getObjectName() occasionally returns null
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
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 src/share/classes/sun/management/ManagementFactoryHelper.java
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.
Cheers
Steve
-------------- next part -------------- A non-text attachment was scrubbed... Name: BufferPoolMXBeanObjectNameStressTest.java Type: text/x-java Size: 2608 bytes Desc: not available Url : http://mail.openjdk.java.net/pipermail/nio-dev/attachments/20110718/edb184e9/attachment.bin -------------- next part -------------- A non-text attachment was scrubbed... Name: jmx.diff Type: text/x-patch Size: 654 bytes Desc: not available Url : http://mail.openjdk.java.net/pipermail/nio-dev/attachments/20110718/edb184e9/attachment-0001.bin
- Previous message: Question about AsynchronousByteChannel.read()
- Next message: java.nio.BufferPoolMXBean getObjectName() occasionally returns null
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]