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

Description

We got a cache of images where we store page-images of pdfs. The stress test (iterating over 18.000 pages) consists of getting a serialized BufferedImage (using a wrapper class which serializes the raw bitmaps and the meta-info). MaxItems in Memory was 10.

Under JDK 1.5 (latest) it ran like hell - no problems.

Under JDK 1.6 (latest) it always aborted with OutOfMemory Errors.

Investigation showed that in the DiskStore spooling was not fast enough - The spool HashMap was growing to around 140 entries and then the VM Heap was exhausted.

Further investigations showed that in the Constructor the spool Threads priority is set to literal “2” which is quite low.

1.5 and 1.6 seem to handle this priority differently.

I fixed our problem by setting the SpoolThread Priority to Thread.NORM_PRIORITY

The problem occurs when the cache can deliver fast (SelfPopulatingCache) without creating the value.

A limit to the spool HashMap size could also fix this problem.

[email protected]

Sourceforge Ticket ID: 1681308 - Opened By: nobody - 15 Mar 2007 10:29 UTC

Comments

Sourceforge Tracker 2009-09-21

Logged In: YES user_id=693320 Originator: NO

Hi

Thanks for reporting and finding this.

I have gone with the Thread.NORM_PRIORITY option.

It is in trunk and will be in ehcache-1.3-beta2.

Greg

Comment by: gregluck - 25 Apr 2007 06:28 UTC

Fiona OShea 2009-09-22

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