Hi, I've been thinking about this whenever I needed a new pool ;) but soon found out that the requirements are always a bit different. We might still want to give it a try because it really gets a bit messy when each module creates and maintains it own pool.
here are the different requirements: - paralleled execution of some work. this is primarily to make use of multi-core processors. execution should be distributed over and executed by N threads which is a factor of the available processors. This is currently implemented in DynamicPooledExecutor, but I guess this could also be split apart, using a generic pooled executor and a utility on top that controls how many commands are executed at a time. - Timers used in TransactionContext and MultiIndex. This could be turned into a scheduling mechanism that could also be used by the ClusterNode sync. Other classes that use periodic checks in a background thread: DatabaseJournal (ClusterRevisionJanitor), CooperativeFileLock (watch dog). - execute work asynchronously (this kind of work might take a longer time to finish): ObservationDispatcher (event notification), IndexMerger the more I think about it, the more I like your idea. but we should be careful with a maximum size for a repository wide pool. extensive use of the pool by a module should not lock up another module just because there are no more idle threads. maybe that global pool shouldn't have a maximum size... regards marcel On Wed, Jul 8, 2009 at 14:37, Jukka Zitting<[email protected]> wrote: > Hi, > > Prompted by the JCR-1818 changes I started thinking whether it would > make sense to have a single per-repository thread pool for use by all > the various background jobs (index merging, text extraction, cluster > sync, etc.) that we have going on while a repository is running. We > could also add simple task scheduling functionality to the pool if > needed. Such a global thread pool would be easier to manage and > configure, though it would reduce the amount of control one has over > the scheduling and capacity of individual tasks. > > WDYT? > > BR, > > Jukka Zitting >
