Return-Path: X-Original-To: apmail-lucene-java-user-archive@www.apache.org Delivered-To: apmail-lucene-java-user-archive@www.apache.org Received: from mail.apache.org (hermes.apache.org [140.211.11.3]) by minotaur.apache.org (Postfix) with SMTP id 905DA9E56 for ; Mon, 20 Feb 2012 03:40:05 +0000 (UTC) Received: (qmail 14352 invoked by uid 500); 20 Feb 2012 03:40:03 -0000 Delivered-To: apmail-lucene-java-user-archive@lucene.apache.org Received: (qmail 14306 invoked by uid 500); 20 Feb 2012 03:40:02 -0000 Mailing-List: contact java-user-help@lucene.apache.org; run by ezmlm Precedence: bulk List-Help: List-Unsubscribe: List-Post: List-Id: Reply-To: java-user@lucene.apache.org Delivered-To: mailing list java-user@lucene.apache.org Received: (qmail 14245 invoked by uid 99); 20 Feb 2012 03:40:00 -0000 Received: from nike.apache.org (HELO nike.apache.org) (192.87.106.230) by apache.org (qpsmtpd/0.29) with ESMTP; Mon, 20 Feb 2012 03:40:00 +0000 X-ASF-Spam-Status: No, hits=-0.7 required=5.0 tests=FSL_RCVD_USER,RCVD_IN_DNSWL_LOW,SPF_PASS X-Spam-Check-By: apache.org Received-SPF: pass (nike.apache.org: domain of trejkaz@trypticon.org designates 209.85.214.176 as permitted sender) Received: from [209.85.214.176] (HELO mail-tul01m020-f176.google.com) (209.85.214.176) by apache.org (qpsmtpd/0.29) with ESMTP; Mon, 20 Feb 2012 03:39:52 +0000 Received: by obbwd18 with SMTP id wd18so9302273obb.35 for ; Sun, 19 Feb 2012 19:39:31 -0800 (PST) Received-SPF: pass (google.com: domain of trejkaz@trypticon.org designates 10.60.29.195 as permitted sender) client-ip=10.60.29.195; Authentication-Results: mr.google.com; spf=pass (google.com: domain of trejkaz@trypticon.org designates 10.60.29.195 as permitted sender) smtp.mail=trejkaz@trypticon.org Received: from mr.google.com ([10.60.29.195]) by 10.60.29.195 with SMTP id m3mr8359840oeh.61.1329709171761 (num_hops = 1); Sun, 19 Feb 2012 19:39:31 -0800 (PST) Received: by 10.60.29.195 with SMTP id m3mr7191668oeh.61.1329709171675; Sun, 19 Feb 2012 19:39:31 -0800 (PST) Received: from mail-wi0-f176.google.com (mail-wi0-f176.google.com [209.85.212.176]) by mx.google.com with ESMTPS id q5sm6754888oef.3.2012.02.19.19.39.29 (version=SSLv3 cipher=OTHER); Sun, 19 Feb 2012 19:39:30 -0800 (PST) Received: by wibhq12 with SMTP id hq12so3673589wib.35 for ; Sun, 19 Feb 2012 19:39:28 -0800 (PST) Received-SPF: pass (google.com: domain of trejkaz@trypticon.org designates 10.180.82.39 as permitted sender) client-ip=10.180.82.39; Received: from mr.google.com ([10.180.82.39]) by 10.180.82.39 with SMTP id f7mr13397655wiy.19.1329709168800 (num_hops = 1); Sun, 19 Feb 2012 19:39:28 -0800 (PST) MIME-Version: 1.0 Received: by 10.180.82.39 with SMTP id f7mr11194481wiy.19.1329709168783; Sun, 19 Feb 2012 19:39:28 -0800 (PST) Received: by 10.180.93.196 with HTTP; Sun, 19 Feb 2012 19:39:28 -0800 (PST) In-Reply-To: <000b01ccef6c$1371bff0$3a553fd0$@thetaphi.de> References: <000b01ccef6c$1371bff0$3a553fd0$@thetaphi.de> Date: Mon, 20 Feb 2012 14:39:28 +1100 Message-ID: Subject: Re: Hanging with fixed thread pool in the IndexSearcher multithread code From: Trejkaz To: java-user@lucene.apache.org Content-Type: text/plain; charset=UTF-8 X-Gm-Message-State: ALoCoQmRP0FrGDqPMEVQTtuXBdtp7pGiRj1VFjtkSFXc9CcHxj/yA57PZvAJNBkVjDY9gf3Y5LQk X-Virus-Checked: Checked by ClamAV on apache.org 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... TX --------------------------------------------------------------------- To unsubscribe, e-mail: java-user-unsubscribe@lucene.apache.org For additional commands, e-mail: java-user-help@lucene.apache.org