Release Notes Ehcache Core 2.5
Release Notes for Ehcache 2.5.4
===============================
Ehcache 2.5.4 is a bug fix release
Resolved Issues
- DEV-6572 - overloaded putIfAbsent API
- DEV-7076 - Possible thread leak when shutting down Ehcache clients on Tomcat 7
- EHC-747 - eternal attribute is confusing
- EHC-959 - getKeys() sometimes returns an incomplete list of keys
- EHC-936 - BlockingCache.putWithWriter not unlocking
- EHC-923 - Hibernate entity cache region is growing over maxEntriesLocalHeap limit
- EHC-920 - CacheManager.create() always calls ConfigurationFactory.parseConfiguration() which causes poor performance loading existing caches
Release Notes for Ehcache 2.5.2
===============================
Ehcache 2.5.2 is a bug fix release
Resolved Issues
- EHC-869 - Maven use with Terracotta very difficult to get going
- EHC-898 - net.sf.ehcache.configurationResourceName is ignored
- EHC-905 - Eviction count always comes as zero
- EHC-909 - Can probably add the java.lang.Class type to the built-in ignore list
- EHC-911 - Cache.isKeyInCache() returns true for pinnedKeys
- EHC-913 - Cache.setMemoryStoreEvictionPolicy isn’t honored for MemoryOnlyStore
- EHC-918 - Deadlock using ehcache as Hibernate second level cache
- EHC-919 - Transient attributes are not ignored in ObjectGraphWalker, causing Ehcache to not work with Groovy
- EHC-920 - CacheManager.create() always calls ConfigurationFactory.parseConfiguration() which causes poor performance loading existing caches
- EHC-927 - ERROR net.sf.ehcache.distribution.RMIAsynchronousCacheReplicator - Exception on flushing of replication queue: null. Continuing… java.lang.NullPointerException
- EHC-931 - Nullpointer at net.sf.ehcache.CacheManager.getCache(CacheManager.java:894)
- EHC-933 - Custom size-of filter loading from resources use the wrong resource name.
- EHC-935 - Add a system property to disable Hibernate value mode optimizations
- EHC-937 - Possible memory leak in xa_strict mode
Release Notes for Ehcache 2.5.1
===============================
Ehcache 2.5.1 is a bug fix release
Resolved Issues
- EHC-882 - Make @IgnoreSizeOf inheritable by users
- EHC-894 - Regression in replace(Element, Element) method on Cache
- EHC-900 - SizeOfPolicy cannot be set/add if TransactionManagerLookup was previously set/add
- EHC-901 - Pinning & Cache.getKeys is Broken
- EHC-903 - Not release lock in SelectableConcurrentHashMap
- EHC-909 - Can probably add the java.lang.Class type to the built-in ignore list
- EHC-910 - Agent shouldn’t put in System props by default
- EHC-913 - Cache.setMemoryStoreEvictionPolicy isn’t honored for MemoryOnlyStore
- DEV-6477 - java.lang.AssertionError in memorystore
- DEV-6571 - Concurrent get requests from lower tiers can cause redundant deserialization
- DEV-6576 - Cryptic error msg from ehcache - “re-allocates CacheManager’s localOffHeap limit!”
- DEV-6639 - SerializablePortability instances hold strong references to serialized types.
- DEV-6783 - CacheException while committing local transactions on decorated cache
Known Issues and Limitations
- 7994 - Terracotta Toolkit 1.5-runtime-ee-4.3.0 is not backward compatible with previous versions of Ehcache. It requires 2.5.4 and higher.
- 5376 - The ehcache xa transactional mode (not xa_strict, that one is fine) doesn’t play 100% well with the Atomikos transaction manager: if all other XA resources participating in the transaction return XA_RDONLY during prepare then Atomikos will mistakenly report the transaction’s status as UNKNOWN instead of COMMITTED, making ehcache rollback the changes.
This is a bug in Atomikos, already reported here: http://fogbugz.atomikos.com/default.asp?community.6.802.3- If this issue arises configuring a mix of xa and xa_strict caches should avoid the issue
- JRockit Issues with versions below r28.
- Workaround: At least version r28 of JRockit must be used when using BigMemory
- On Firefox and Chrome the Ehcache Monitor charts may go blank. http://www.sencha.com/forum/showthread.php?78788-OPEN-197-3.0.0-svn-5208-this.swf.setDataprovider-is-not-a-function
- Workaround: refresh browser
- We recommend using a 64bit JVM when using BigMemory. With 32bit JVMs the total addressable memory (on-heap and off-heap is limited by the 32bit address space AND some JVM version specific limits that vary depending on the operating system they are running on). For Example with 32bit JRockit, the max addressable memory is about 3.6GB, permitting up to 2.8GB off-heap and 800MB on-heap. For 32bit Hotspot the max off-heap size is typically <2GB. Some experimentation may be required.