JDK-6289795 : "fair" lock policy in ReentrantLock may cause busy hang
  • Type: Bug
  • Component: core-libs
  • Sub-Component: java.util.concurrent
  • Affected Version: 5.0
  • Priority: P4
  • Status: Closed
  • Resolution: Duplicate
  • OS: solaris_9
  • CPU: sparc
  • Submitted: 2005-06-23
  • Updated: 2010-04-02
  • Resolved: 2005-06-23
Related Reports
Duplicate :  
Description
FULL PRODUCT VERSION :
java version "1.5.0"
Java(TM) 2 Runtime Environment, Standard Edition (build 1.5.0-b64)
Java HotSpot(TM) Client VM (build 1.5.0-b64, mixed mode, sharing)


ADDITIONAL OS VERSION INFORMATION :
SunOS telehouse2 5.9 Generic_112233-11 sun4u sparc SUNW,UltraSPARC-IIi-cEngine

Linux mirror-us-ga1.gallery.hd.org 2.4.21-27.0.2.EL #1 Wed Jan 19 02:20:34 GMT 2005 i686 i686 i386 GNU/Linux


EXTRA RELEVANT SYSTEM CONFIGURATION :
Highly concurrent JSP/J2EE Web app (http://gallery.hd.org/)

A DESCRIPTION OF THE PROBLEM :
Simply switching to a "fair" locking policy seems to cause the app to hang consuming 100% CPU.

See value of USE_FAIR_LOCKS in:

http://gallery.hd.org/_javadoc/org/hd/d/pg2k/webSvr/exhibit/ExhibitDataHTTPTunnelSource.html

and:

http://gallery.hd.org/_javadoc/src-html/org/hd/d/pg2k/webSvr/exhibit/ExhibitDataHTTPTunnelSource.html#line.87

STEPS TO FOLLOW TO REPRODUCE THE PROBLEM :
Simply changing this policy flag seems to cause a hang if true, not if false, rather than just a subtle performance change.  It could of course be something subtle in my code, but there should not even be much contention for these locks most of the time.


ERROR MESSAGES/STACK TRACES THAT OCCUR :
Here is a relevant hung thread...

"DataSourceBean: poll() thread" daemon prio=10 tid=0x01b5c028 nid=0x83 runnable
[0xcee7f000..0xcee7f9c8]
        at java.util.concurrent.locks.AbstractQueuedSynchronizer.fullGetFirstQue
uedThread(AbstractQueuedSynchronizer.java:1280)
        at java.util.concurrent.locks.AbstractQueuedSynchronizer.getFirstQueuedT
hread(AbstractQueuedSynchronizer.java:1233)
        at java.util.concurrent.locks.ReentrantLock$FairSync.tryAcquire(Reentran
tLock.java:208)
        at java.util.concurrent.locks.AbstractQueuedSynchronizer.tryAcquireNanos
(AbstractQueuedSynchronizer.java:1087)
        at java.util.concurrent.locks.ReentrantLock.tryLock(ReentrantLock.java:4
16)
        at org.hd.d.pg2k.webSvr.exhibit.ExhibitDataHTTPTunnelSource.doRPCRaw(Unk
nown Source)
        at org.hd.d.pg2k.svrCore.datasource.ExhibitDataTunnelSource.doRPCUnguard
ed(Unknown Source)
        at org.hd.d.pg2k.svrCore.datasource.ExhibitDataTunnelSource.getGenProps(
Unknown Source)
        at org.hd.d.pg2k.svrCore.datasource.ExhibitDataSimpleCache._getGenProps(
Unknown Source)
        at org.hd.d.pg2k.svrCore.datasource.ExhibitDataSimpleCache.poll(Unknown
Source)
        at org.hd.d.pg2k.webSvr.exhibit.DataSourceBean.poll(Unknown Source)
        at org.hd.d.pg2k.webSvr.exhibit.DataSourceBean$1.run(Unknown Source)



REPRODUCIBILITY :
This bug can be reproduced always.

CUSTOMER SUBMITTED WORKAROUND :
Avoiding "fair" policy for now.
###@###.### 2005-06-23 09:01:17 GMT

Comments
EVALUATION Doug Lea writes: "I'm sure that your problem was the same as bug 6241823" 6241823 still needs to be backported to Tiger update. ###@###.### 2005-06-23 19:07:58 GMT
23-06-2005