lucene-java-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Benson Margulies <bimargul...@gmail.com>
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 <trejkaz@trypticon.org> wrote:
> On Mon, Feb 20, 2012 at 12:07 PM, Uwe Schindler <uwe@thetaphi.de> 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: java-user-unsubscribe@lucene.apache.org
> For additional commands, e-mail: java-user-help@lucene.apache.org
>

---------------------------------------------------------------------
To unsubscribe, e-mail: java-user-unsubscribe@lucene.apache.org
For additional commands, e-mail: java-user-help@lucene.apache.org


Mime
View raw message