EhCache upgrade 1.7.1 to 2.10.1

[Brian G]

I was reading through some ehcache notes and noticed a mention that EhCache 2 returned memory usage levels to pre-1.6 levels (apparently 1.7 used more memory). I thought; I wonder if I could upgrade? And so far, the answer is yes! I haven't put this into production yet so can't claim any live results, but it may be worth a try if you want to squeeze some performance (and upgrade about 8 years worth of ehCache development...)

The process was simple:

* Download ehcache-2.10.1.jar, log4j-1.2.17.jar, slf4j-api-1.7.14.jar and slf4j-log4j12-1.7.14.jar
* Replace the existing Jars in transfer/com/cache/provider/ehcache/ehcache-lib/
* Add a name parameter to your ehcache.xml file like: <ehcache xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:noNamespaceSchemaLocation="http://ehcache.org/ehcache.xsd" name="transferCacheManager"> - this isn't strictly necessary but if you try to recreate transfer in the application scope, it will fail unless you add this name because it will find an existing, unnamed cache.
* Restart

I think that's all I did. The cacheReport tag doesn't work with the new version but I have updated it to work if anyone uses that. I'm going to test this a bit further to see if there are any wins in production but it was surprisingly easy.


Brian

[Tom de Manincor]

Brian,

I have actually done something similar but had to make some additional changes to support shutting down the existing ehCache so that lingering threads aren't left behind as active/live when an app is re-initialized.

I've also beefed up the cache monitoring with Google Charts.

We should connect on this. I would like to discuss the cache name issue with you.

I was waiting to give it time on prod before putting anything up on github.

The bad news...I am still having memory leak issues.

I've seen some huge improvements watching the heap climb from 500MB to 4.5 GB and then purge back down to 1.5 GB but over a few days that lower watermark rises until it gets close to the max and crashes my instance.

The heap analysis in MAT points to lots of coldfusion.tagext.lang.LockTag and the lockName "transfer.composition.XXXX"

I will create another post for the memory leak issue once I feel I have exhausted my investigation on it.

On another note, I've made some updates to TransferSync, as well. One being something you mention in your blog posts a long time back.

I need to find the time to setup all my CF projects on GitHub and get them updated.

Glad to see your still at it with Transfer, too.

[Tom de Manincor]

I have been at this for quite a bit and seem to have hit a dead end.

I have implemented the fix for the CF bug having to do with the coldfusion.util.Key references and that helped with the previous leak.

However, it has revealed another serious memory leak pointing to the FacadeFactory.cfc, InstanceFacade.cfc, EventManager.cfc, and a lot of *ObserverCollection.cfc

If I had to guess I would say it looks like these references are preventing garbage collection on objects that have been discarded or should have been discarded from the cache.

I looked at the CacheManager.cfc and noticed only discardAll deals with the clearing the FacadeFactory.

So I am curious what happens when ehCache evicts or expires cached objects...are these references created by the FacadeFactory hanging around unless a discardAll() is called?

I'm going to keep at it, but would love to hear if anyone else is experiencing this or has any input.

Thanks