jackrabbit-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jukka Zitting <jukka.zitt...@gmail.com>
Subject Re: Per-repository thread pool in Jackrabbit
Date Sun, 12 Jul 2009 20:12:06 GMT

2009/7/8 Marcel Reutegger <marcel.reutegger@gmx.net>:
> - 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

> - 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).


Jukka Zitting

View raw message