Interesting discussion. There are two problems we had been discussion from my understanding.
1. Global/Main pool or sub-pools for repository wide thread management. Marcel listed a few requirement that each of them may need a separate pool, every pool may have different pool size and other configuration, they shouldn't inter affect each other. So a repository wide global/main pool won't fit in this case. My vote is to have multiple pools managed for repository works. 2. The place to mange the pool for repository. The pools settings will affect the performance of repository significantly and thread pools are expensive resource. Undoubtedly the pools should be configurable with a standalone repository because our test are running in this model. As repository may live inside sling or other OSGi/Application Server container which may already have the pool management functionality, so the repository pool would be managed by container. The pool management may need consider this situation during implementation. Just my 2 cents :) --Guo On Sun, Jul 12, 2009 at 9:12 PM, Jukka Zitting <[email protected]>wrote: > Hi, > > 2009/7/8 Marcel Reutegger <[email protected]>: > > - 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. > > If I recall correctly we debated this already earlier. My point was > that limiting the number of tasks to the number of available > processors may not be a good approach as the tasks may be IO-bound or > block for other reasons, in which case having more task threads would > give you better throughput. But I recall being proven wrong, did we > have some benchmark for that? Do you remember where this discussion > was? > > > - 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). > > Yep. Perhaps we could also reuse some of the scheduling functionality in > Sling. > > > 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... > > That might make sense. Perhaps we should have some concept of > sub-pools (that borrow from the main pool) with fixed limits for tasks > that need them (see above). > > BR, > > Jukka Zitting > -- Kind regards, Du, Guo __________________________________________________ Phone : +353-86-176 6186 Email : [email protected] __________________________________________________ http://duguo.com - Career Life Balance
