Don't rely on looking at the files in the index directory to tell if an optimize has been performed.
http://www.nabble.com/what%27s-up-with%3A-java--Ddata%3Dargs--jar-post.jar-%22%3Coptimize-%3E%22-to16162870.html#a16179673 -Yonik On Fri, May 16, 2008 at 12:00 AM, Eason. Lee <[EMAIL PROTECTED]> wrote: > similar problem I met before was using the <optimize/> operation > The first time I sent <optimize/> to solr , the optimize operation did have > down. > But files were not merged. When i sent another <optimize/> to solr, all the > files were merged. > This seems to happen just in Windows > > > 2008/5/13, Yonik Seeley <[EMAIL PROTECTED]>: >> >> 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 <[EMAIL PROTECTED]> >> wrote: >> > Erik: I am indeed issuing multiple Solr requests. >> > >> > Here is my code snippet (deletexml and addxml are the strings that >> contain >> > the <add> and <delete> 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("<commit waitFlush=\"true\" >> > waitSearcher=\"true\"/>"); >> > } >> > >> > I am using the full form of the commit here just to see if the <commit >> /> >> > 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" <[EMAIL PROTECTED]> >> > Sent: Tuesday, May 13, 2008 7:40 AM >> > >> > >> > To: <solr-user@lucene.apache.org> >> > Subject: Re: Commit problems on Solr 1.2 with Tomcat >> > >> > >> > > I'm not sure if you are issuing a separate <commit/> _request_ >> after your >> > <add>, or putting a <commit/> 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 <commit /> 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 <commit /> 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 <commit /> command everything seems to >> > work. Why are TWO commit commands apparently required? >> > > > >> > > > Thanks, >> > > > >> > > > Sridhar >> > > > >> > > > -------------------------------------------------- >> > > > From: "Yonik Seeley" <[EMAIL PROTECTED]> >> > > > Sent: Tuesday, May 13, 2008 6:42 AM >> > > > To: <solr-user@lucene.apache.org> >> > > > 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 >> > > > > <[EMAIL PROTECTED]> wrote: >> > > > > >> > > > > > Maybe a delay in commit? How may time elapsed between commits? >> > > > > > >> > > > > > 2008/5/13 William Pierce <[EMAIL PROTECTED]>: >> > > > > > >> > > > > > >> > > > > > >> > > > > > > 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 <add> and <commit> a >> > single >> > > > > > > document to an index. After I add the document and issue the >> > <commit /> 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 <commit/>, 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 >> > > > > > >> > > > > > >> > > > > >> > > > >> > > >> > > >> > > >> > >> >