• Task
  • Status: Closed
  • 2 Major
  • Resolution: Fixed
  • ehcache-core
  • cdennis
  • Reporter: jabley
  • November 17, 2009
  • 0
  • Watchers: 1
  • March 26, 2010
  • February 09, 2010

Attachments

Description

Initially reported on the mailing list [1]

Seen on 1.6.12 but apparently 1.7.x behaves the same way.

DiskStore.getI() is synchronized. This means that applications using the DiskStore will see sequential behaviour if hitting the DiskStore lots. This issue has been raised to investigate potential improvements around that.

[1] http://lists.terracotta.org/pipermail/ehcache-list/2009-November/000086.html

Comments

Alex Miller 2009-11-17

assess for 1.7.1

James Abley 2009-11-26

Initial draft for tests

James Abley 2009-12-04

We’re currently running a patch for this in production. If I don’t see any problems with it in the next couple of days, I’l submit it here.

V N 2009-12-08

Where can I take the patch?

We are also using EhCache persisted to disk in and it becomes slow when data grows up to ~30 GBytes on disk. And all threads are blocked waiting on DiskStore. I would like to test it too.

James Abley 2009-12-14

http://gist.github.com/248153 - that’s the patch against trunk that I tried, but we had problems with a liveness failure in the memory cache.

http://gist.github.com/248157 - that’s the patch made against 1.6.2, which we were running with previously. We have that patched version in production with no problems and have seen no incidences of the problem for over a week. We were seeing the problem on a daily basis prior to that. Statistics from the cache indicate that we are seeing no statistically significant changes in the cache hits, etc.

James Abley 2009-12-14

Patches against trunk and 1.6.2 code bases as described in the comment.

V N 2010-01-25

Thank you for the patch!

I have tested 1.6.2 with the patch in production - definitely, it works much much faster on our 30-40 Gbytes files. The shudown is also quick now. It would be great to incorporate this into SVN and latest builds.

Fiona OShea 2010-01-26

Is this safe?

James Abley 2010-01-28

Is there anything more I can do to help with this? We’d like to run a released version rather than a patched version, to give us an easier migration path.

V N 2010-01-28

If I understand correctly, latest 1.7 releases do not contain this fix/patch? If so, EhCache developers could add the fix to 1.7.

Chris Dennis 2010-01-28

I’m currently reviewing this patch for possible inclusion in the Darwin release. I’ll post back to here when I’ve made a decision.

Chris Dennis 2010-02-09

I’ve checked in a slightly modified version of James Abley’s patch. The main difference is that rather the configuring the access stripes from the number of processors reported by the Runtime object we set it from the ehcache config file (diskAccessStripes=”4” for example).

V N 2010-03-26

I can confirm, it is fast enough now in 2.0. Thanks a lot!