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

Description

The DiskStore is intended to have asynchronous behaviour. However, under contention it degrades to nearly synchronous behaviour.

There are multiple reasons for this:

1) The spool thread (and the expiry thread) both run at the normal priority level. 2) The spool thread locks the entire DiskStore. 3) The spool thread is notified immediately upon an entry being placed in the spool. This means that it is instantly contending for the lock, and has a good chance of getting in before anything else. 4) While the spool thread is de-spooling, no other entries can be added to the DiskStore.

A test can be easily created Create a Cache with a small MemoryStore, and put in significantly more elements (e.g. a cache size of 10, and 10000 elements) in a loop. The degraded performance should be obvious.

The easiest fix is to lower the priority of the spool and expiry thread.

A better fix is to not have the spool or expiry thread lock the spool while interacting with the disk. Ideally, clients should be able to: 1) Add new entries to the store 2) Retrieve entries that happen to be in the disk spool still 3) Query for the presence of an entry in the store

all while the spooling is occuring. This could be done by using locks on the individual DiskElement and the backing file, instead of just the DiskStore.

If I get a chance, I’ll see if I can get a patch made. Sourceforge Ticket ID: 1332728 - Opened By: robertdw - 20 Oct 2005 00: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