United StatesChange Country, Oracle Worldwide Web Sites Communities I am a... I want to...
Bug ID: JDK-6705524 OOPP/General: Concurency issues (properties r/w, JREInfo r/w, CleanupThread, removeDuplicateEntries)
JDK-6705524 : OOPP/General: Concurency issues (properties r/w, JREInfo r/w, CleanupThread, removeDuplicateEntries)

Details
Type:
Bug
Submit Date:
2008-05-21
Status:
Closed
Updated Date:
2011-05-13
Project Name:
JDK
Resolved Date:
2008-06-27
Component:
deploy
OS:
generic,windows
Sub-Component:
plugin
CPU:
x86,generic
Priority:
P3
Resolution:
Fixed
Affected Versions:
6u10
Fixed Versions:
6u10 (b26)

Related Reports
Duplicate:
Relates:
Relates:

Sub Tasks

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
EVALUATION

see suggested fix
                                     
2008-05-21
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
                                     
2008-05-22



Hardware and Software, Engineered to Work Together