Return-Path: Delivered-To: apmail-lucene-java-user-archive@www.apache.org Received: (qmail 63322 invoked from network); 4 Sep 2008 21:36:25 -0000 Received: from hermes.apache.org (HELO mail.apache.org) (140.211.11.2) by minotaur.apache.org with SMTP; 4 Sep 2008 21:36:25 -0000 Received: (qmail 64463 invoked by uid 500); 4 Sep 2008 21:36:15 -0000 Delivered-To: apmail-lucene-java-user-archive@lucene.apache.org Received: (qmail 64428 invoked by uid 500); 4 Sep 2008 21:36:15 -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 64417 invoked by uid 99); 4 Sep 2008 21:36:15 -0000 Received: from athena.apache.org (HELO athena.apache.org) (140.211.11.136) by apache.org (qpsmtpd/0.29) with ESMTP; Thu, 04 Sep 2008 14:36:15 -0700 X-ASF-Spam-Status: No, hits=2.0 required=10.0 tests=HTML_MESSAGE,SPF_PASS X-Spam-Check-By: apache.org Received-SPF: pass (athena.apache.org: domain of leonidms@gmail.com designates 209.85.200.171 as permitted sender) Received: from [209.85.200.171] (HELO wf-out-1314.google.com) (209.85.200.171) by apache.org (qpsmtpd/0.29) with ESMTP; Thu, 04 Sep 2008 21:35:17 +0000 Received: by wf-out-1314.google.com with SMTP id 28so140416wfc.20 for ; Thu, 04 Sep 2008 14:35:48 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from:to :subject:in-reply-to:mime-version:content-type:references; bh=UaSUjfV37iRxLQLJ0VSSD1rC3hEwfuo8M2dlFlVJYtA=; b=e8gWJsgaCNb4JrAxsDcbyh1m/1D7D7bJE4aBkHy1Rp0h8ez6Zub6Sx7SF8CqSgP8YO gpfB+ET8P47Bm9BOVsc0QyrJ318pg3rPpHRq/bPmmVx1JrUuMJZWg1O1ofMEzUNdQsXg IBvaPHSyx36DsVcxV5wy2IDMydDkzINtbjUY4= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:to:subject:in-reply-to:mime-version :content-type:references; b=dLFeqHLhtyDW2XIz8Q/ctJ/itIuI34RZpx81ESdc/+6vFk9L/ELzXSWQjMGCBXrBjj uxs84Yx/FL4hHHUNMD+QzJ1GwEsdhXuMAYzpwYbllH3P3o9tNhrrX7arl4ezkdhEPTK/ 1rIErqGpUYuX0lJ21+nfd6SZrGFnSeEPal6WM= Received: by 10.142.166.1 with SMTP id o1mr3740312wfe.345.1220564147518; Thu, 04 Sep 2008 14:35:47 -0700 (PDT) Received: by 10.143.41.4 with HTTP; Thu, 4 Sep 2008 14:35:47 -0700 (PDT) Message-ID: Date: Fri, 5 Sep 2008 00:35:47 +0300 From: "Leonid M." To: java-user@lucene.apache.org Subject: Re: Problem with lucene search starting to return 0 hits when a few seconds earlier it was returning hundreds In-Reply-To: <858644.37668.qm@web45215.mail.sp1.yahoo.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_Part_63882_13864871.1220564147518" References: <858644.37668.qm@web45215.mail.sp1.yahoo.com> X-Virus-Checked: Checked by ClamAV on apache.org ------=_Part_63882_13864871.1220564147518 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Content-Disposition: inline * And what's about visibility filter? * Are you sure no one else accesses IndexReader and modifies index? See reader.maxDocs() to be confident. On Fri, Sep 5, 2008 at 12:19 AM, Justin Grunau wrote: > We have some code that uses lucene which has been working perfectly well > for several months. > > Recently, a QA team in our organization has set up a server with a much > larger data set than we have ever tested with in the past: the resulting > lucene index is about 3G in size. > > On this particular server, the same lucene code which has been reliable in > the past is now exhibiting erratic behavior. The first time you do a > search, it returns the correct number of hits. The second time you do a > search, it may or may not return the correct set. By the third time you do > a search, it will return 0 hits even for a search that was returning > hundreds of hits only a few seconds earlier. All subsequent searches will > return 0 hits until you stop and restart the java process. > > A snippet of the relevant code follows: > > // getReader() returns the singleton IndexReader object > final IndexReader reader = getReader(); > > // ANALYZER is another singleton > final QueryParser queryParser = new QueryParser("text", > ANALYZER); > queryParser.setDefaultOperator(spec.getDefaultOp()); > final Query query = > queryParser.parse(spec.getSearchText()).rewrite( > reader); > final IndexSearcher searcher = new IndexSearcher(reader); > > final Hits hits = searcher.search(query, new > CachingWrapperFilter( > new QueryWrapperFilter(visibilityFilter))); > total = hits.length(); > > > > I understand that Lucene should be able to handle very large datasets, so > I'd be surprised if this were an actual Lucene bug. I'm hoping it's just > that I'm doing something "wrong" which has gone unnoticed so far for several > months because we've never had an index this large. > > We're using lucene verison 2.2.0. > > Thanks! > > Justin Grunau > > > > > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: java-user-unsubscribe@lucene.apache.org > For additional commands, e-mail: java-user-help@lucene.apache.org > > -- Bests regards, Leonid Maslov! Personal blog: http://leonardinius.blogspot.com/ Random thought: Princess Margaret - "I have as much privacy as a goldfish in a bowl." ------=_Part_63882_13864871.1220564147518--