Community
Participate
Working Groups
The MoDisco org.eclipse.gmt.modisco.java.discoverer.cdo component uses the org.eclipse.emf.cdo.common component. A method signature has recently evolved (Indigo RC1 build) on one non-internal CDO class : org.eclipse.emf.cdo.common.revision.CDORevisionUtil. The public static method createRevisionCache() has disappeared. A new method createRevisionCache(boolean, boolean) is now available.
Just out of curiosity, why are you creating the revision cache yourself?
A fix has been commited into SVN (rev 4408) to enable RC1 MoDisco build. Gregoire you will have to approve the patchs I will add.
Created attachment 195963 [details] JavaDiscovererCDO patch
Created attachment 195964 [details] old JavaDiscovererCDO patch
(In reply to comment #1) > Just out of curiosity, why are you creating the revision cache yourself? Hello, Since two years we try to use CDO to solve code discovery scalability problems. We tried to use different configuration of CDO including the different RevisionCache. A CDO documentation provides information about that: http://wiki.eclipse.org/CDO/Tweaking_Performance#Tweaking_the_CDORevisionCaches Since the bug 329887 (Indigo M3), the revisionCache customization has been disabled. Here is the peace of code which use the CDORevisionCache: CDORevisionCache revisionCache = CDORevisionUtil.createRevisionCache(); // TODO Bug 329887 // if (cacheType.equals(JavaDiscovererCDO.MEM_CACHE)) { // revisionCache = CDORevisionCacheUtil.createMEMCache(); // } else if (cacheType.equals(JavaDiscovererCDO.LRU_CACHE)) { // revisionCache = CDORevisionCacheUtil.createLRUCache( // JavaDiscovererCDO.DEFAULT_LRU_CAPACITY, // JavaDiscovererCDO.DEFAULT_LRU_CAPACITY); // } else if (cacheType.equals(JavaDiscovererCDO.TWO_LEVEL_CACHE)) { // revisionCache = CDORevisionCacheUtil.createTwoLevelCache( // CDORevisionCacheUtil.createLRUCache( // JavaDiscovererCDO.LRU_CAPACITY_CURRENT, // JavaDiscovererCDO.LRU_CAPACITY_REVISED), // CDORevisionCacheUtil.createMEMCache()); // } This code is contained by the method org.eclipse.gmt.modisco.java.discoverer.cdo.JavaDiscovererCDO.getOrCreateCDOResource(String, EPackage, String, int) Regards, Gregoire Dupe
Hi Gregoire, It is still possible to override the (CDO) system default for the revision cache implementation with the SPI method org.eclipse.emf.cdo.spi.common.revision.InternalCDORevisionManager.setCache(CDORevisionCache). That said, we came to the conclusion that the additional complexity of maintaining implementations like LRURevisionCache faces almost no efficiency gains, especially since we introduced the new branching mode. Rather than fostering fundamentally different cache implemenations that must support all three modes (non-auditing, auditing and branching) we've decided to come up with only three fundamental implementations, each optimized for exactly one mode. Instances of these cache types are created by org.eclipse.emf.cdo.common.revision.CDORevisionUtil.createRevisionCache(boolean, boolean). We've not kept the old mode-agnostic factory method to make this fundamental paradigm change obvious to our users. In particular for the non-auditing mode cache users that deal with really huge models (transform of big COBOL programs) have reported enormous footprint decreases.
Bug solved.
