jackrabbit-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Guo Du <mrdu...@gmail.com>
Subject Re: Per-repository thread pool in Jackrabbit
Date Sun, 12 Jul 2009 22:19:39 GMT
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 <jukka.zitting@gmail.com>wrote:

> Hi,
>
> 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
> 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     : online@duguo.com
__________________________________________________
http://duguo.com  - Career Life Balance

Mime
View raw message