On Sun, Feb 19, 2012 at 10:39 PM, Trejkaz <trej...@trypticon.org> wrote: > On Mon, Feb 20, 2012 at 12:07 PM, Uwe Schindler <u...@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-unsubscr...@lucene.apache.org > For additional commands, e-mail: java-user-h...@lucene.apache.org > --------------------------------------------------------------------- To unsubscribe, e-mail: java-user-unsubscr...@lucene.apache.org For additional commands, e-mail: java-user-h...@lucene.apache.org
