• Documentation
  • Status: Open
  • 2 Major
  • Resolution:
  • ehcache
  • Reporter: sivsan
  • April 08, 2010
  • 0
  • Watchers: 1
  • October 11, 2011


We have defined many cache in ehcache,xml and use one CacheManager to load all the Cache. We were under the impression that the loader will be invoked for each unique key within a cache, but what we see is that only one loader per cache is running at any give point. All others threads are queued as future task. Unfortunately, we are dealing with large set of non-Oracle based data whichtook long time to load.

If a loader instance takes 40 seconds to complete the request, all other futuretask arewaiting until the first one complete. This makes the waiting thead long and Websphere assumes there were hung and the whole JVM is going cracy. We cant use the application until all the future tasks are killed or completed.

This looks to me EHCache is a single threaded model. No two keys get loaded in the a same Cache in parellel. Am i wrong? Is there are way can i load multiple loader to load the elements for differentkey without going throw the FIFO queue. If i could run 10 loader instance simultenously, we should be able to make the EHCache work in our environment., Thank you for your help.


Siva Nallu 2010-04-10

I have looked the code more closly and found that Cache.java is using Core Pool Size as 1. So all the calls are queued as future task. until the first call completes. I have tested many ways there is no way to increase the core pool size. How do we handle this issue? If there is a way we can increase the corep pool size using a configurable parameter, our isdsue will be resolved. If this is not possible, how Ido address this issue. At this time, all the calls are going as single threaded which makes all users wait.In the peak load some of our cache loader takes upto 10 seconds complete execution for the first time when a key is added to the cache. If 10 users accessthe system, the 10th user will only get the responseafter 100 seconds. It is terribilily impacting the application now. Any help would be greatly apprreciated.

Fiona OShea 2010-09-01

Moving all unresolved “Fix Revision 2.2.1” to fix revision “unknown” as we are releasing Magnum first which is 2.3. Currently not sure which fix version these will actually be in, but they are targeted for Fremantle release

Fiona OShea 2011-02-22

MOving unresolved P2 jiras to Ulloa - to be reviewed by Chris, Fiona, Greg soon