[exo-jcr-commits] exo-jcr SVN: r4413 - in jcr/branches/1.12.x: exo.jcr.component.core/src/test/resources/conf/standalone/cluster and 1 other directories.

[do-not-reply at jboss.org]

Author: paristote
Date: 2011-05-23 22:09:14 -0400 (Mon, 23 May 2011)
New Revision: 4413

Added:
   jcr/branches/1.12.x/patch/1.12.9-GA/JCR-1629/readme.txt
Modified:
   jcr/branches/1.12.x/exo.jcr.component.core/src/main/resources/conf/portal/cluster/jbosscache-indexer.xml
   jcr/branches/1.12.x/exo.jcr.component.core/src/test/resources/conf/standalone/cluster/test-jbosscache-indexer.xml
Log:
JCR-1629

What is the problem to fix?
  * For indexing, JBC is used as the temporary/transactional/cluster aware memory such that if we add an eviction policy we could miss some nodes to index 
moreover using eviction algorithm such as FIFO add some contention.

How is the problem fixed?
  * Removing eviction policy from configuration



Modified: jcr/branches/1.12.x/exo.jcr.component.core/src/main/resources/conf/portal/cluster/jbosscache-indexer.xml
===================================================================
--- jcr/branches/1.12.x/exo.jcr.component.core/src/main/resources/conf/portal/cluster/jbosscache-indexer.xml	2011-05-23 13:26:34 UTC (rev 4412)
+++ jcr/branches/1.12.x/exo.jcr.component.core/src/main/resources/conf/portal/cluster/jbosscache-indexer.xml	2011-05-24 02:09:14 UTC (rev 4413)
@@ -9,12 +9,4 @@
       <jgroupsConfig multiplexerStack="jcr.stack" />
       <sync />
    </clustering>
-   <!-- Eviction configuration -->
-   <eviction wakeUpInterval="5000">
-      <default algorithmClass="org.jboss.cache.eviction.FIFOAlgorithm" eventQueueSize="1000000">
-         <property name="maxNodes" value="10000" />
-         <property name="minTimeToLive" value="60000" />
-      </default>
-   </eviction>
-
 </jbosscache>

Modified: jcr/branches/1.12.x/exo.jcr.component.core/src/test/resources/conf/standalone/cluster/test-jbosscache-indexer.xml
===================================================================
--- jcr/branches/1.12.x/exo.jcr.component.core/src/test/resources/conf/standalone/cluster/test-jbosscache-indexer.xml	2011-05-23 13:26:34 UTC (rev 4412)
+++ jcr/branches/1.12.x/exo.jcr.component.core/src/test/resources/conf/standalone/cluster/test-jbosscache-indexer.xml	2011-05-24 02:09:14 UTC (rev 4413)
@@ -11,12 +11,4 @@
       <jgroupsConfig multiplexerStack="jcr.stack" />
       <sync />
    </clustering>
-   <!-- Eviction configuration -->
-   <eviction wakeUpInterval="5000">
-      <default algorithmClass="org.jboss.cache.eviction.FIFOAlgorithm" eventQueueSize="1000000">
-         <property name="maxNodes" value="10000" />
-         <property name="minTimeToLive" value="60000" />
-      </default>
-   </eviction>
-
 </jbosscache>

Added: jcr/branches/1.12.x/patch/1.12.9-GA/JCR-1629/readme.txt
===================================================================
--- jcr/branches/1.12.x/patch/1.12.9-GA/JCR-1629/readme.txt	                        (rev 0)
+++ jcr/branches/1.12.x/patch/1.12.9-GA/JCR-1629/readme.txt	2011-05-24 02:09:14 UTC (rev 4413)
@@ -0,0 +1,65 @@
+Summary
+
+    Status: No eviction policy is allowed in case of the cache for indexing
+    CCP Issue: N/A, Product Jira Issue: JCR-1629.
+    Complexity: Low
+
+The Proposal
+Problem description
+
+What is the problem to fix?
+For indexing, JBC is used as the temporary/transactional/cluster aware memory such that if we add an eviction policy we could miss some nodes to index moreover using eviction algorithm such as FIFO add some contention.
+Fix description
+
+How is the problem fixed?
+
+** *removing eviction policy from configuration
+
+     
+
+Patch information:
+JCR-1629.patch
+
+Tests to perform
+
+Reproduction test
+  * No
+
+Tests performed at DevLevel
+  * functional testing in jcr-core project
+
+Tests performed at QA/Support Level
+*
+
+Documentation changes
+
+Documentation changes:
+  * No
+
+Configuration changes
+
+Configuration changes:
+  * Eviction policy is removed from cache index configuration
+
+Will previous configuration continue to work?
+  * Yes
+
+Risks and impacts
+
+Can this bug fix have any side effects on current client projects?
+    No
+
+Is there a performance risk/cost?
+  * No
+
+Validation (PM/Support/QA)
+
+PM Comment
+*
+
+Support Comment
+*
+
+QA Feedbacks
+*
+