• New Feature
  • Status: Resolved
  • 2 Major
  • Resolution: Won't Fix
  • ehcache-core
  • searchScalability
  • teck
  • Reporter: teck
  • October 11, 2010
  • 0
  • Watchers: 1
  • August 21, 2013
  • August 21, 2013

Description

For un-indexed queries on large caches it might be useful to use multiple threads to perform the search (provided there is more than 1 core available).

The element set iterator of the compound store isn’t thread safe so you’d likely have to wrap that and let each worker thread grab many elements while synchronized on the iterator.

Need to think about how users want to specify / control thread numbers and pools before going to far with this

Comments

gluck 2010-10-11

Like a scatter gather, but using cores instead of Terracotta L2s.

Petr H 2010-10-21

Looks interesting, perhaps use of java.lang.Runtime availableProcessors method to get amount ov available CPUs should be incorporated here as well (as one of options) http://download.oracle.com/javase/1.5.0/docs/api/java/lang/Runtime.html#availableProcessors%28%29

Tim Eck 2013-08-21

I don’t suspect this approach or really much attention at all will be given to standalone (ie. brute force algo) search