I added some comments on this issue related to when it occurs and a unit test 
to easily reproduce it. In order to fix it, I see the following possibilities:

1. Make some minimal (couple of lines) changes in the PropertyCache that will 
change the order that locks are acquired. Specifically, if a map segment needs 
cleaning, the lock on the segment should be released, a lock on votesForRehash 
should be acquired and then, if a rehash is required, all the segment locks 
will be acquired.

The only drawback of this is that the votesForRehash lock will be held if a 
segment needs only cleaning and there is no need for rehash. The attached test 
runs successfully after making those changes.

2. Base the implementation of PropertyCache on the JDK5 ConcurrentHashMap and 
get rid of most of this code.

3. Use some more advances jdk5 constructs (as the ones used in 
ConcurrentHashMap) instead of the synchronized blocks.

Since FOP is now using JDK5, my preferred solution is number 2. The JDK5 
implementation, except having no known bugs, is also likely to perform better 
in terms of performance and size. Also, it needs good expertise on concurrent 
programming and time to maintain a concurrent map implementation (and this bug 
was opened 2 years ago). 

So, what do you say ?


Reply via email to