lucene-java-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Benson Margulies <>
Subject Re: Hanging with fixed thread pool in the IndexSearcher multithread code
Date Mon, 20 Feb 2012 11:56:05 GMT
On Sun, Feb 19, 2012 at 10:39 PM, Trejkaz <> wrote:
> On Mon, Feb 20, 2012 at 12:07 PM, Uwe Schindler <> wrote:
>> See my response. The problem is not in Lucene; its in general a problem of fixed
>> thread pools that execute other callables from within a callable running at the
>> moment in the same thread pool. Callables are simply waiting for each other.
> What we do to get around this issue is to have a utility class which
> you call to submit jobs to the executor, but instead of waiting after
> submitting them, it starts calling get() starting from the end of the
> list. So if there is no other thread available on the executor, the
> main thread ends up doing all the work and then returns like normal.
> The problem with this solution is that it requires all code in the
> system to go through this utility to avoid the issue, and obviously
> Lucene is one of those things which isn't written to defend against
> this.
> Java 7's solution seems to be ForkJoinPool but I gather there is no
> simple way to use that with Lucene...

I take it that a pool which rejects too much work (instead of blocking
for a slot) is just as bad from a Lucene standpoint.

> TX
> ---------------------------------------------------------------------
> To unsubscribe, e-mail:
> For additional commands, e-mail:

To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message