Return-Path: Delivered-To: apmail-lucene-solr-user-archive@locus.apache.org Received: (qmail 69183 invoked from network); 16 May 2008 04:01:04 -0000 Received: from hermes.apache.org (HELO mail.apache.org) (140.211.11.2) by minotaur.apache.org with SMTP; 16 May 2008 04:01:04 -0000 Received: (qmail 5481 invoked by uid 500); 16 May 2008 04:00:59 -0000 Delivered-To: apmail-lucene-solr-user-archive@lucene.apache.org Received: (qmail 5454 invoked by uid 500); 16 May 2008 04:00:59 -0000 Mailing-List: contact solr-user-help@lucene.apache.org; run by ezmlm Precedence: bulk List-Help: List-Unsubscribe: List-Post: List-Id: Reply-To: solr-user@lucene.apache.org Delivered-To: mailing list solr-user@lucene.apache.org Received: (qmail 5443 invoked by uid 99); 16 May 2008 04:00:59 -0000 Received: from athena.apache.org (HELO athena.apache.org) (140.211.11.136) by apache.org (qpsmtpd/0.29) with ESMTP; Thu, 15 May 2008 21:00:59 -0700 X-ASF-Spam-Status: No, hits=3.5 required=10.0 tests=HTML_MESSAGE,SPF_PASS,WEIRD_PORT X-Spam-Check-By: apache.org Received-SPF: pass (athena.apache.org: domain of leongfans@gmail.com designates 72.14.220.156 as permitted sender) Received: from [72.14.220.156] (HELO fg-out-1718.google.com) (72.14.220.156) by apache.org (qpsmtpd/0.29) with ESMTP; Fri, 16 May 2008 04:00:10 +0000 Received: by fg-out-1718.google.com with SMTP id l27so753117fgb.27 for ; Thu, 15 May 2008 21:00:24 -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=L0b1G0slrz5bmWKzA0AIXfUC+uiaC55+8Tql9lsKO4w=; b=PUJkV59M9zjKrPzzMPmVteUnb6fNX2xzCTW/V4xEK/QiL4RPydOHud2HTP21XY4pdWxxuNO3ufk+22KjhJS8Gxt6ia1D+b6Z8NTP7pdo+Me6GnlX26JJ3d2p5vHrHpQDdOAh96vX7rJiBCghWMSGy49gt+vnEq95eKAkHkjGwA8= 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=SpsdAR1gIPYQlBbTfypZafHwkggWEmsU0EP/Q6daWS+iKg10jE67NqG06UV60MjWpLEVcal1tGaXpRlfqSu2sAOzs54XmGBNuNlB0Dnzp6YFQ7py4jkTA7sCxKnCoDb8E5hHQJza6QEvFmeYvZQdkgyh38/oj1g067tYxYy5OY0= Received: by 10.125.132.15 with SMTP id j15mr2050145mkn.144.1210910423064; Thu, 15 May 2008 21:00:23 -0700 (PDT) Received: by 10.86.53.1 with HTTP; Thu, 15 May 2008 21:00:23 -0700 (PDT) Message-ID: Date: Fri, 16 May 2008 12:00:23 +0800 From: Eason.Lee To: solr-user@lucene.apache.org Subject: Re: Commit problems on Solr 1.2 with Tomcat In-Reply-To: MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_Part_7070_23464045.1210910423052" References: <1aeed5b20805130631t1cd2d826qe292b7457394ca76@mail.gmail.com>

<1E755496-A898-48F0-B1E5-AEF42F038096@ehatchersolutions.com> X-Virus-Checked: Checked by ClamAV on apache.org ------=_Part_7070_23464045.1210910423052 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline similar problem I met before was using the operation The first time I sent to solr , the optimize operation did have down. But files were not merged. When i sent another to solr, all the files were merged. This seems to happen just in Windows 2008/5/13, Yonik Seeley : > > Is SendSolrIndexingRequest synchronous or asynchronous? > If the call to SendSolrIndexingRequest() can return before the > response from the add is received, then the commit could sneak in and > finish *before* the add is done (in which case, you won't see it > before the next commit). > > -Yonik > > On Tue, May 13, 2008 at 10:49 AM, William Pierce > wrote: > > Erik: I am indeed issuing multiple Solr requests. > > > > Here is my code snippet (deletexml and addxml are the strings that > contain > > the and strings for the items to be added or deleted). > For > > our simple example, nothing is being deleted so "stufftodelete" is > always > > false. > > > > //we are done...we now need to post the requests... > > if (stufftodelete) > > { > > SendSolrIndexingRequest(deletexml); > > } > > if (stufftoadd) > > { > > SendSolrIndexingRequest(addxml); > > } > > > > if ( stufftodelete || stufftoadd) > > { > > SendSolrIndexingRequest(" > waitSearcher=\"true\"/>"); > > } > > > > I am using the full form of the commit here just to see if the /> > > was somehow not working. > > > > The SendSolrIndexingRequest is the routine that takes the string > argument > > and issues the POST request to the update URL. > > > > Thanks, > > > > Bill > > > > -------------------------------------------------- > > From: "Erik Hatcher" > > Sent: Tuesday, May 13, 2008 7:40 AM > > > > > > To: > > Subject: Re: Commit problems on Solr 1.2 with Tomcat > > > > > > > I'm not sure if you are issuing a separate _request_ > after your > > , or putting a into the same request. Solr only supports > > one command (add or commit, but not both) per request. > > > > > > Erik > > > > > > > > > On May 13, 2008, at 10:36 AM, William Pierce wrote: > > > > > > > > > > Thanks for the comments.... > > > > > > > > The reason I am just adding one document followed by a commit is for > > this particular test --- in actuality, I will be loading documents from > a > > db. But thanks for the pointer on the ?commit=true on the add command. > > > > > > > > Now on the problem itself, I am still confused: Doesn't > > the commit count of 1 indicate that the commit is completed? > > > > > > > > In any event, just for testing purposes, I started everything from > > scratch (deleted all documents, stopped/restarted tomcat). I noticed > that > > the only files in my index folder were: segments.gen and segments_1. > > > > > > > > Then I did the add followed by and noticed that > there were > > now three files: segments.gen, segments_1 and write.lock. > > > > > > > > Now it is 7 minutes later, and when I query the index using the > > "http://localhost:59575/splus1/admin/" url, I still do not see the > document. > > > > > > > > Again, when I issue another command everything seems to > > work. Why are TWO commit commands apparently required? > > > > > > > > Thanks, > > > > > > > > Sridhar > > > > > > > > -------------------------------------------------- > > > > From: "Yonik Seeley" > > > > Sent: Tuesday, May 13, 2008 6:42 AM > > > > To: > > > > Subject: Re: Commit problems on Solr 1.2 with Tomcat > > > > > > > > > > > > > By default, a commit won't return until a new searcher has been > > opened > > > > > and the results are visible. > > > > > So just make sure you wait for the commit command to return before > > querying. > > > > > > > > > > Also, if you are committing every add, you can avoid a separate > > commit > > > > > command by putting ?commit=true in the URL of the add command. > > > > > > > > > > -Yonik > > > > > > > > > > On Tue, May 13, 2008 at 9:31 AM, Alexander Ramos Jardim > > > > > wrote: > > > > > > > > > > > Maybe a delay in commit? How may time elapsed between commits? > > > > > > > > > > > > 2008/5/13 William Pierce : > > > > > > > > > > > > > > > > > > > > > > > > > Hi, > > > > > > > > > > > > > > I am having problems with Solr 1.2 running tomcat > version 6.0.16 > > (I also > > > > > > > tried 6.0.14 but same problems exist). Here is > the situation: > > I have an > > > > > > > ASP.net application where I am trying to and a > > single > > > > > > > document to an index. After I add the document and issue the > > I > > > > > > > can see (in the solr stats page) that the commit count > has been > > increment > > > > > > > but the docsPending is 1, and my document is still > not visible > > from a > > > > > > > search perspective. > > > > > > > > > > > > > > When I issue another , the commit counter > increments, > > > > > > > docsPending is now zero, and my document is visible and > > searchable. > > > > > > > > > > > > > > I saw that someone was observing problems with 6.0.16 tomcat, > > so I > > > > > > > reverted back to 6.0.14. Same problem. > > > > > > > > > > > > > > Can anyone help? > > > > > > > > > > > > > > -- Bill > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > -- > > > > > > Alexander Ramos Jardim > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > ------=_Part_7070_23464045.1210910423052--