Hi, 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 ? Alexis
