Mailing-List: contact dev-help@jackrabbit.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@jackrabbit.apache.org
Received-SPF: pass (athena.apache.org: domain of jukka.zitting@gmail.com
 designates 209.85.220.224 as permitted sender)
DomainKey-Signature: a=rsa-sha1; c=nofws;
        d=gmail.com; s=gamma;
        h=mime-version:in-reply-to:references:date:message-id:subject:from:to
         :content-type:content-transfer-encoding;
        b=urlOiZtSwHP8eCW9i3hfrP2M4jvt2lHfVmG3MNIa++wH6p//S0oU3ec16AJi6bxc33
         lvOGaiAIo5rr3u/5+uwlAw9aiHcqGv4NDlhYq3E2qMoYpKSZBTZv1i89Wai7I1e47zWp
         XxUzmi9g2oBqWwdJE5kB+VSzmvhjVSS6L7xw0=
MIME-Version: 1.0
In-Reply-To: <a781e7950907080625r3f3311e2n68bb358f98625031@mail.gmail.com>
References: <510143ac0907080537n465db1d7r192d4d417a025de3@mail.gmail.com>
	 <a781e7950907080625r3f3311e2n68bb358f98625031@mail.gmail.com>
Date: Sun, 12 Jul 2009 22:12:06 +0200
Message-ID: <510143ac0907121312h4f084672sdbdf9413907d8485@mail.gmail.com>
Subject: Re: Per-repository thread pool in Jackrabbit
From: Jukka Zitting <jukka.zitting@gmail.com>
To: dev <dev@jackrabbit.apache.org>
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit

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