JDK-6705524 : OOPP/General: Concurency issues (properties r/w, JREInfo r/w, CleanupThread, removeDuplicateEntries)
  • Type: Bug
  • Component: deploy
  • Sub-Component: plugin
  • Affected Version: 6u10
  • Priority: P3
  • Status: Closed
  • Resolution: Fixed
  • OS: generic,windows
  • CPU: generic,x86
  • Submitted: 2008-05-21
  • Updated: 2011-05-13
  • Resolved: 2008-06-27
The Version table provides details related to the release that this issue/RFE will be addressed.

Unresolved : Release in which this issue/RFE will be addressed.
Resolved: Release in which this issue/RFE has been resolved.
Fixed : Release in which this issue/RFE has been fixed. The release containing this fix may be available for download as an Early Access Release or a General Availability Release.

To download the current JDK release, click here.
JDK 6
6u10 b26Fixed
Related Reports
Duplicate :  
Relates :  
Relates :  
Description
Running many OOPP(w/o JNLP) applets in many JVMs (optional)
reveils concurrency bugs in a few components.

Config's properties r/w and JREInfo r/w were neither thread safe
nor process safe (ie through many JVM instances).

The CleanupThread's locking was flaky and 
the call of Cache.removeDuplicateEntries() is invalid,
as we have no reliable way to determine if an entry is being used 
on the whole platform and maybe even network wide, in case of a nfs mounted cache.

Cache.removeDuplicateEntries() contained a bug, 
preventing it from removing duplicate entries.

Comments
SUGGESTED FIX 6705524 OOPP/General: Concurency issues (properties r/w, JREInfo r/w, CleanupThread, removeDuplicateEntries) [ Kenneth Russel, Thomas Ng ] Thomas.Ng's approval is pending. - com/sun/deploy/cache/Cache.removeDuplicateEntries() - removed busy==false criteria for selection, since it is always true per default and lead to no removal at all - Adding test of MemoryCache.contains(urlString), to avoid removing entries already in use within this JVM - com/sun/deploy/cache/CleanupThread.java A cleanup trigger as in startCleanup() shall not block the caller at all, but trigger the cleanup only. If a cleanup is already running, nothing has to be done and we can return immediatly as well. Idea: No blocking at all in the call of startCleanup(). Hence the synchronized(this) {} block in the run body was just too wide, and shall only encapsulate the this.wait() state. Fixed. Removed 'Cache.removeDuplicateEntries()' from cleanup task, since there is currently no reliable way to tell if a duplicate ressource in in use by this JVM or another JVM. - com/sun/deploy/util/SyncAccess.java New utility to have shared read and exclusive write locking for any purpose in the Java realm only. This implements a 2-way mutex using sychronized and a volatile bitfield for the desired operation, currently read and write. - com/sun/deploy/util/SyncFileAccess.java New utility utilizing SyncAccess and FileLock to achieve JVM and system wide file access synchronization. - com/sun/deploy/config/JREInfo Using SyncAccess for synchronized read/write operations on the local and global data. - com/sun/deploy/config/Config Using SyncFileAccess for synchronized read/write operations on deployment.properties +++ testcase: http://j2se.east.sun.com/deployment/www/tests/1.6.0_10/6705524/ webrev: http://sa.sfbay.sun.com/projects/deployment_data/6u10/6705524.2/ workspace: deploy engineer: sven.gothel
22-05-2008

EVALUATION see suggested fix
21-05-2008