Community
Participate
Working Groups
Build Identifier: 4.0 Just recenty stumbled over this stacktrace while testing: Caused by: java.util.ConcurrentModificationException at java.util.HashMap$HashIterator.nextEntry(HashMap.java:793) at java.util.HashMap$EntryIterator.next(HashMap.java:834) at java.util.HashMap$EntryIterator.next(HashMap.java:832) at org.eclipse.emf.cdo.internal.common.revision.cache.branch.BranchRevisionCache.getRevisions(BranchRevisionCache.java:206) at org.eclipse.emf.internal.cdo.transaction.CDOTransactionImpl.createRevisionAvailabilityInfo(CDOTransactionImpl.java:371) at org.eclipse.emf.internal.cdo.transaction.CDOTransactionImpl.merge(CDOTransactionImpl.java:340) ... 42 more It happened in 1 of our 10'000 random tests, couldn't reproduce since. But when looking at BranchRevisionCache, it looks as if access to revisionLists is not consistently synchronized. Reproducible: Sometimes
Created attachment 180652 [details] Proposed patch Added synchronized access to revisionList. 1) The number of lines that you changed is smaller than 250. confirmed. 2) You are the only author of these changed lines. confirmed. 3) You apply the EPL to these changed lines. confirmed.
As such the synchronizations in getAllRevisions() and getRevisions(CDOBranchPoint) limit concurrency a lot if called. But these methods are really not supposed to be called in regular server operations. Currently they're only called on the client, which seems acceptable. So we probably don't need more opimized solutions ;-) Committed to HEAD
Available in R20110608-1407