CDV ❯ no tim-hibernate tests fail despite using a TC 2.7 version of tim-ehcache-1.3
-
Bug
-
Status: Closed
-
2 Major
-
Resolution: Fixed
-
-
-
wharley
-
Reporter: teck
-
March 03, 2009
-
0
-
Watchers: 1
-
April 10, 2009
-
March 27, 2009
Description
The underlying problem in the POM has already been fixed, but this item is to figure out why no tests failed.
If you rollback http://svn.terracotta.org/fisheye/changelog/TerracottaForge/?cs=14326 in trunk tim-hibernate and rebuild you should end up with a tim-hibernate-3.2.5 TIM artifact that depends on tim-ehcache-1.3-1.2.4-SNAPSHOT (which is for TC 2.7). If the code in that tim-ehcache TIM actually runs, it should fail b/c of an API change in ManagerUtil.
The assertion is that no hibernate test that covers this path where the ehcache TIM is used.
Comments
Walter Harley 2009-03-25
Walter Harley 2009-03-25
Hmm, noticed this in the server log, might be a clue:
18:24:00,616 WARN net.sf.ehcache.config.ConfigurationFactory - No configuration found. Configuring ehcache from ehcach e-failsafe.xml found in the classpath: jar:file:/Users/wharley/dev/forge/projects/trunk/tim-hibernate/tim-hibernate-3.2 .5-system-tests/target/temp/ContainerHibernate325Test/sandbox/server_0/webapps/events/WEB-INF/lib/ehcache-1.3.0.jar!/ehc ache-failsafe.xml
Walter Harley 2009-03-26
Yes, that’s the problem. If I name the ehcache.xml file with a full path in the hibernate.cfg.xml, and speed up eviction so that the eviction code is called, then pointing to the 1.2.4 version of tim-ehcache results in the expected “no such method” errors in the log.
However, these errors are still not causing an actual test failure, because they’re on a thread that doesn’t kill the test:
Exception in thread “CacheInvalidator - org.hibernate.cache.StandardQueryCache invalidation thread0” com.tc.exception.TC RuntimeException: java.lang.NoSuchMethodError: com.tc.object.bytecode.Manager.beginLock(Ljava/lang/String;I)V at com.tcclient.cache.CacheEntryInvalidator.run(CacheEntryInvalidator.java:99) at com.tcclient.cache.CacheInvalidationTimer$EvictionRunner.run(CacheInvalidationTimer.java:53) at java.lang.Thread.run(Thread.java:637) Caused by: java.lang.NoSuchMethodError: com.tc.object.bytecode.Manager.beginLock(Ljava/lang/String;I)V at com.tcclient.cache.Lock.writeLock(Lock.java:53) at com.tcclient.cache.CacheEntryInvalidator.run(CacheEntryInvalidator.java:87) … 2 more
Walter Harley 2009-03-27
Fixed in Forge trunk with change 14547 (to tim-ehcache) and 14548 (to tim-hibernate).
Basically there were several problems:
-
ehcache config was not properly being loaded; needed to include relative pathname to it, in hibernate cfg file.
-
ehcache eviction interval was long enough that the evictor threads were never being run in the context of the hibernate tests.
-
Even when asynchronous eviction failed, synchronous eviction (on the get() call) still succeeded, so eviction happens even despite the NoSuchMethodErrors.
To fix this, I’ve added a test that explicitly looks for cross-cluster cacheing and subsequent eviction, and that also verifies (by doing a thread dump and scanning for thread names) that the evictor threads are still running.
The test code relies on a constant added to tim-ehcache, so it is no longer possible to even compile against the 2.7.4 version. However, by temporarily hard-coding the constant value, I have verified that the test does fail in this scenario.
nadeem ghani 2009-04-03
mvn clean install in tim-hibernate/trunk fails if tim-ehcache version is anything older than 1.3.0-SNAPSHOT
So far I’m really wrestling with this one. The tim-hibernate test ContainerHibernate325Test *should* be testing this. It configures Hibernate to use a second-level cache and sets that cache to EHCache, configures ehcache properly (as far as I can tell), and declares the tim-ehcache module; it even asserts that there is a cache hit. Debugging code inserted in tim-ehcache confirms that instrumentation is happening, but it does not seem the instrumentation code is ever called (unlike in tim-ehcache tests, where it does get called). So possibly the cache hit is local, and we are not actually distributing the ehcache? I am not sure how to force that to happen.