Return-Path: Delivered-To: apmail-lucene-java-user-archive@www.apache.org Received: (qmail 8985 invoked from network); 24 Sep 2007 22:15:06 -0000 Received: from hermes.apache.org (HELO mail.apache.org) (140.211.11.2) by minotaur.apache.org with SMTP; 24 Sep 2007 22:15:06 -0000 Received: (qmail 2576 invoked by uid 500); 24 Sep 2007 22:14:50 -0000 Delivered-To: apmail-lucene-java-user-archive@lucene.apache.org Received: (qmail 2546 invoked by uid 500); 24 Sep 2007 22:14:50 -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 2535 invoked by uid 99); 24 Sep 2007 22:14:50 -0000 Received: from athena.apache.org (HELO athena.apache.org) (140.211.11.136) by apache.org (qpsmtpd/0.29) with ESMTP; Mon, 24 Sep 2007 15:14:50 -0700 X-ASF-Spam-Status: No, hits=-0.0 required=10.0 tests=SPF_PASS X-Spam-Check-By: apache.org Received-SPF: pass (athena.apache.org: domain of markrmiller@gmail.com designates 64.233.162.239 as permitted sender) Received: from [64.233.162.239] (HELO nz-out-0506.google.com) (64.233.162.239) by apache.org (qpsmtpd/0.29) with ESMTP; Mon, 24 Sep 2007 22:14:48 +0000 Received: by nz-out-0506.google.com with SMTP id i28so918059nzi for ; Mon, 24 Sep 2007 15:14:28 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=beta; h=domainkey-signature:received:received:message-id:date:from:user-agent:mime-version:to:subject:references:in-reply-to:content-type:content-transfer-encoding; bh=GMMbjLOR6Pf/vJG73nd8PQM3Q7SgFxk2/A+0itIH+QM=; b=JVtOnIV4KO8OCXT5whj357ZVZP4jN7yRFLfBsWb3dCH6gjDDpetdO5/msDpgeZluRmqqukpw2/BK887gSTxY/D6BvWVEpLaj7HZbpRkEt6RB52Urw4LAIG1qVjVrdMVWA3e5o59V/bXryhfTEGzTp9K3+JSNHh3VF30SQShGXgc= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:message-id:date:from:user-agent:mime-version:to:subject:references:in-reply-to:content-type:content-transfer-encoding; b=BDxKdRNF0fFS8og2a79atLusYFBssr0cQAn44YAgK9bVdxn3fsCorqiNjegXoKyd5Nb+UEmZBTbL/6AcFVzLn3ZLjCUKeMrSPrSN9wUVCXWUb/nlho7FB4ZNJnm68i8D52Utis6l+Fq8GxTOyAOhaPjJvKIITKT3O5LNpQN6XsU= Received: by 10.65.234.2 with SMTP id l2mr7891658qbr.1190672067603; Mon, 24 Sep 2007 15:14:27 -0700 (PDT) Received: from ?192.168.1.108? ( [69.124.234.183]) by mx.google.com with ESMTPS id z21sm2472022qbc.2007.09.24.15.14.25 (version=SSLv3 cipher=RC4-MD5); Mon, 24 Sep 2007 15:14:26 -0700 (PDT) Message-ID: <46F8366F.1090806@gmail.com> Date: Mon, 24 Sep 2007 18:13:03 -0400 From: Mark Miller User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: java-user@lucene.apache.org Subject: Re: thread safe shared IndexSearcher References: <46F15AE1.5040400@ai.sri.com> <46F171FB.2080306@ai.sri.com> <46F1A8B5.1030401@ai.sri.com> <46F1D862.8000201@gmail.com> <46F2959D.9040403@ai.sri.com> <46F29849.4070701@gmail.com> <46F299A4.6030403@ai.sri.com> <46F7A320.9030100@gmail.com> <46F7E9F9.3010103@ai.sri.com> In-Reply-To: <46F7E9F9.3010103@ai.sri.com> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Checked: Checked by ClamAV on apache.org I have sat down and rewrote IndexAccessor from scratch. I copied in the same reference counting logic, pruned some things, and tried to make the whole package a bit simpler to use. I have a few things to do, but its pretty solid already. The only major thing I'd still like to do is add an option to warm searchers before putting them in the Searcher cache. Id like to writer some more tests as well. Any help greatly appreciated if your interested in using the thing. http://myhardshadow.com/indexaccessor/trunk/src/test/com/mhs/indexaccessor/SimpleSearchServer.java Here is a an example of a class that can be instantiated in one of multiple threads and read /modify a single index without worrying about what any of the other threads are doing to the index at any given time. This is a very simple example of how to use the IndexAccessor and not necessarily an example of best practices. The main idea is that you get your Writer, Searcher, or Reader, and then be sure to release it as soon as your done with it in a finally block. For loading, you will want to load many docs with a Writer (batch them) before releasing it, but remember that Readers will not get a new view of the index until you release all of the Writers. So beware hogging a Writer unless you thats what your intending. JavaDoc: http://myhardshadow.com/indexaccessorapi/ Code: http://myhardshadow.com/indexaccessor/trunk/ Jar: http://myhardshadow.com/indexaccessorreleases/indexaccessor.jar Your synchronized block concerns: The synchronized blocks that control accesss to the IndexAccessor do not have a huge impact on performance. Keep in mind that all of the work is not done in a synchonrized block, just the retrieval of the Searcher, Writer, Reader. Even if the synchronization makes the method twice as expensive, it is still overpowered by the cost of parsing queries and searching the index. This applies with or without contention. I wrote a simple test and included the output below. You might use the IBM Lock Analyzer for Java to further analyze these costs. Trust me, this thing is speedy. Its many times better than using IndexModifier. Without Contention Just retrieve and release Searcher 100000 times ---- avg time:6.3E-4 ms total time:63 ms Parse query and search on 1 doc 100000 times ---- avg time:0.03107 ms total time:3107 ms With Contention (40 other threads running 80000 searches) Just retrieve and release Searcher 100000 times ---- avg time:0.04643 ms total time:4643 ms Parse query and search on 1 doc 100000 times ---- avg time:0.64337 ms total time:64337 ms - Mark --------------------------------------------------------------------- To unsubscribe, e-mail: java-user-unsubscribe@lucene.apache.org For additional commands, e-mail: java-user-help@lucene.apache.org