Re: [xwiki-devs] [xwiki-notifications] r10858 - in xwiki-platform/core/trunk/xwiki-cache/xwiki-cache-jbosscache/src: main/java/org/xwiki/cache/jbosscache/internal test/java/org/xwiki/cache/jbosscache
On Jun 26, 2008, at 9:05 PM, tmortagne (SVN) wrote:
Author: tmortagne Date: 2008-06-26 21:05:24 +0200 (Thu, 26 Jun 2008) New Revision: 10858
Modified: xwiki-platform/core/trunk/xwiki-cache/xwiki-cache-jbosscache/src/ main/java/org/xwiki/cache/jbosscache/internal/ JBossCacheCacheConfiguration.java xwiki-platform/core/trunk/xwiki-cache/xwiki-cache-jbosscache/src/ test/java/org/xwiki/cache/jbosscache/JBossCacheCacheTest.java Log: XWIKI-1744: Use JBoss Cache by default in XWiki * improve JBoss cache configuration loading
[snip]
public void testCreateAndDestroyCacheLRUMaxEntries() throws ComponentLookupException, Exception { - /*CacheFactory factory = getCacheFactory(); + CacheFactory factory = getCacheFactory();
CacheConfiguration conf = new CacheConfiguration(); LRUEvictionConfiguration lec = new LRUEvictionConfiguration(); lec.setMaxEntries(1); + // Force JBoss eviction interval to the minimum + lec.put(JBossCacheCacheConfiguration.CONFX_EVICTION_WAKEUPINTERVAL, 1); conf.put(LRUEvictionConfiguration.CONFIGURATIONID, lec);
Cache<Object> cache = factory.newCache(conf); @@ -36,19 +39,24 @@
cache.set("key2", 2);
+ // Wait for the JBoss Eviction policy to be called + Thread.sleep(1000);
warning, warning, warning! (insert flashing lights here) [snip]
assertEquals("value", cache.get("key"));
- Thread.sleep(1000); + // Wait for the JBoss Eviction policy to be called + Thread.sleep(3000);
Same, but worse... :) This reminds me of the setSpeed() in our selenium tests that I've removed in the RMUI tests. Note that I'm not proposing a solution since I have no clue and haven't read the code yet. BTW isn't it dangerous to switch cache implementation in a RC? I'd say it is.... I don't even think we've tested it in any real instance so I'd be -0 to do that before testing it in real for several days/week. WDYT? Thanks -Vincent
On Thu, Jun 26, 2008 at 9:23 PM, Vincent Massol <[email protected]> wrote:
On Jun 26, 2008, at 9:05 PM, tmortagne (SVN) wrote:
Author: tmortagne Date: 2008-06-26 21:05:24 +0200 (Thu, 26 Jun 2008) New Revision: 10858
Modified: xwiki-platform/core/trunk/xwiki-cache/xwiki-cache-jbosscache/src/ main/java/org/xwiki/cache/jbosscache/internal/ JBossCacheCacheConfiguration.java xwiki-platform/core/trunk/xwiki-cache/xwiki-cache-jbosscache/src/ test/java/org/xwiki/cache/jbosscache/JBossCacheCacheTest.java Log: XWIKI-1744: Use JBoss Cache by default in XWiki * improve JBoss cache configuration loading
[snip]
public void testCreateAndDestroyCacheLRUMaxEntries() throws ComponentLookupException, Exception { - /*CacheFactory factory = getCacheFactory(); + CacheFactory factory = getCacheFactory();
CacheConfiguration conf = new CacheConfiguration(); LRUEvictionConfiguration lec = new LRUEvictionConfiguration(); lec.setMaxEntries(1); + // Force JBoss eviction interval to the minimum + lec.put(JBossCacheCacheConfiguration.CONFX_EVICTION_WAKEUPINTERVAL, 1); conf.put(LRUEvictionConfiguration.CONFIGURATIONID, lec);
Cache<Object> cache = factory.newCache(conf); @@ -36,19 +39,24 @@
cache.set("key2", 2);
+ // Wait for the JBoss Eviction policy to be called + Thread.sleep(1000);
warning, warning, warning! (insert flashing lights here)
[snip]
assertEquals("value", cache.get("key"));
- Thread.sleep(1000); + // Wait for the JBoss Eviction policy to be called + Thread.sleep(3000);
Same, but worse... :)
This reminds me of the setSpeed() in our selenium tests that I've removed in the RMUI tests.
The way JBossCache eviction policy works it run in another thread and is launched at an interval which can be less than 1s
Note that I'm not proposing a solution since I have no clue and haven't read the code yet.
BTW isn't it dangerous to switch cache implementation in a RC? I'd say it is.... I don't even think we've tested it in any real instance so I'd be -0 to do that before testing it in real for several days/week. WDYT?
For now I did not switch anything because as you said the JBossCache implementation has not been sufficiently tested in the real world. I just wanted to attach this commit to a context because it's too little to deserve it's own jira issue.
Thanks -Vincent
_______________________________________________ devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs
-- Thomas Mortagne
On Thu, Jun 26, 2008 at 9:37 PM, Thomas Mortagne <[email protected]> wrote:
On Thu, Jun 26, 2008 at 9:23 PM, Vincent Massol <[email protected]> wrote:
On Jun 26, 2008, at 9:05 PM, tmortagne (SVN) wrote:
Author: tmortagne Date: 2008-06-26 21:05:24 +0200 (Thu, 26 Jun 2008) New Revision: 10858
Modified: xwiki-platform/core/trunk/xwiki-cache/xwiki-cache-jbosscache/src/ main/java/org/xwiki/cache/jbosscache/internal/ JBossCacheCacheConfiguration.java xwiki-platform/core/trunk/xwiki-cache/xwiki-cache-jbosscache/src/ test/java/org/xwiki/cache/jbosscache/JBossCacheCacheTest.java Log: XWIKI-1744: Use JBoss Cache by default in XWiki * improve JBoss cache configuration loading
[snip]
public void testCreateAndDestroyCacheLRUMaxEntries() throws ComponentLookupException, Exception { - /*CacheFactory factory = getCacheFactory(); + CacheFactory factory = getCacheFactory();
CacheConfiguration conf = new CacheConfiguration(); LRUEvictionConfiguration lec = new LRUEvictionConfiguration(); lec.setMaxEntries(1); + // Force JBoss eviction interval to the minimum + lec.put(JBossCacheCacheConfiguration.CONFX_EVICTION_WAKEUPINTERVAL, 1); conf.put(LRUEvictionConfiguration.CONFIGURATIONID, lec);
Cache<Object> cache = factory.newCache(conf); @@ -36,19 +39,24 @@
cache.set("key2", 2);
+ // Wait for the JBoss Eviction policy to be called + Thread.sleep(1000);
warning, warning, warning! (insert flashing lights here)
[snip]
assertEquals("value", cache.get("key"));
- Thread.sleep(1000); + // Wait for the JBoss Eviction policy to be called + Thread.sleep(3000);
Same, but worse... :)
This reminds me of the setSpeed() in our selenium tests that I've removed in the RMUI tests.
The way JBossCache eviction policy works it run in another thread and is launched at an interval which can be less than 1s
can=can't
Note that I'm not proposing a solution since I have no clue and haven't read the code yet.
BTW isn't it dangerous to switch cache implementation in a RC? I'd say it is.... I don't even think we've tested it in any real instance so I'd be -0 to do that before testing it in real for several days/week. WDYT?
For now I did not switch anything because as you said the JBossCache implementation has not been sufficiently tested in the real world. I just wanted to attach this commit to a context because it's too little to deserve it's own jira issue.
Thanks -Vincent
_______________________________________________ devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs
-- Thomas Mortagne
-- Thomas Mortagne
On Jun 26, 2008, at 9:37 PM, Thomas Mortagne wrote: [snip]
BTW isn't it dangerous to switch cache implementation in a RC? I'd say it is.... I don't even think we've tested it in any real instance so I'd be -0 to do that before testing it in real for several days/week. WDYT?
For now I did not switch anything because as you said the JBossCache implementation has not been sufficiently tested in the real world. I just wanted to attach this commit to a context because it's too little to deserve it's own jira issue.
oh ok I was tricked by the issue title... Thanks -Vincent
On Thu, Jun 26, 2008 at 9:45 PM, Vincent Massol <[email protected]> wrote:
On Jun 26, 2008, at 9:37 PM, Thomas Mortagne wrote:
[snip]
BTW isn't it dangerous to switch cache implementation in a RC? I'd say it is.... I don't even think we've tested it in any real instance so I'd be -0 to do that before testing it in real for several days/week. WDYT?
For now I did not switch anything because as you said the JBossCache implementation has not been sufficiently tested in the real world. I just wanted to attach this commit to a context because it's too little to deserve it's own jira issue.
oh ok I was tricked by the issue title...
No problem it was not so clear ;)
Thanks -Vincent
_______________________________________________ devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs
-- Thomas Mortagne
participants (2)
-
Thomas Mortagne -
Vincent Massol