• Bug
  • Status: Closed
  • Resolution: Fixed
  • drb
  • Reporter: sourceforgetracker
  • September 21, 2009
  • 0
  • Watchers: 0
  • September 22, 2009
  • September 22, 2009

Description

We’ve recently converted our application to use EhCache as the 2nd-level cache for Hibernate. During high cache load, we have found that the system experienced CPU usage and load average spikes (8 CPU Sun Solaris) - disabling the disk store removed these spikes.

After reviewing the code, it appears that the thread-per-store, combined with polling and excessive locking are the culprits.

Proposing a few modifications that will improve DiskStore performance, and allow for greater extensiblity. Interested in feedback from the EhCache maintainers before we start to work on these changes.

1) Add support for pluggable disk stores. The high-level steps for this are: a) Create a DiskStore interface; b) Modify configuration to accept a disk store implementation class; c) Modify Cache.java to create appropriate disk store

2) Create alternate DiskStore implementation; high-level design: a) Use the same concepts as existing store (RandomAccessFile, in memory and persistent index); b) Create a Java 5 ThreadPoolExecutor (fallback to a Java 1.4 compatible equivalent - util.concurrent) for spooling of objects; this would result in a pool of threads to spool objects (vs the existing thread-per-store polling method). c) Remove / reduce synchronization on get(); this will be accomplished by using concurrent hash maps and RandomAccessFile.fileChannel(); a Java 1.4 implementation will also be provided (not as performant).

Thoughts?

Chris Lee [email protected] Sourceforge Ticket ID: 1555497 - Opened By: nobody - 9 Sep 2006 20:02 UTC

Comments

Fiona OShea 2009-09-22

Re-opening so that I can properly close out these issues and have correct Resolution status in Jira