Mailing-List: contact accumulo-dev-help@incubator.apache.org; run by ezmlm
Precedence: bulk
Reply-To: accumulo-dev@incubator.apache.org
Received-SPF: neutral (nike.apache.org: local policy)
MIME-Version: 1.0
In-Reply-To: <4EB06EB6.1090004@digitalreasoning.com>
References: <4EB04FE3.5020005@digitalreasoning.com>
	<CAGUtCHqfK2nR2Cp=w3zGf6Wu=AhB5PAHB_qzy1Y+6VaAGZVsxQ@mail.gmail.com>
	<4EB06EB6.1090004@digitalreasoning.com>
Date: Tue, 1 Nov 2011 22:53:36 -0400
Message-ID: 
 <CAGUtCHrsztqabDu5zMjHok+1EX4HAET6Sw8T1neZE_02upaY5g@mail.gmail.com>
Subject: Re: ScannerIterator thread use
From: Keith Turner <keith@deenlo.com>
To: accumulo-dev@incubator.apache.org
Content-Type: text/plain; charset=ISO-8859-1

On Tue, Nov 1, 2011 at 6:12 PM, Keith Massey
<keith.massey@digitalreasoning.com> wrote:
>
> I'm not incredibly familiar with this code, but it could be a static thread
> pool right? And just let all ScannerIterators share some configurable thread
> pool? The thread would just be returned to the pool when the Reader
> completed.
>

When I think of thread pools, I always think of setting an upper bound
on the number of threads.  It occurred to me that we could use a
static thread pool if it were unbounded.  This would replicate the
current behavior and allow for thread reuse.  So make the core size
small (0,1 or 2),  the max size MAX_INT, the timeout small (few
seconds), and use a SynchronousQueue.  Everything added to the pool
should create a new thread if one is not available.  Also make the
threads daemon threads so they do not keep the process alive.