Actually, I've recently seen very similar behavior in Solr 4.10.3, but involving hard commits openSearcher=true, see: https://issues.apache.org/jira/browse/SOLR-7572. Of course I can't reproduce this at will, siigggghhhh.
A unit test should be very simple to write though, maybe I can get to it today. Erick On Fri, May 22, 2015 at 8:27 AM, Upayavira <u...@odoko.co.uk> wrote: > > > On Fri, May 22, 2015, at 03:55 PM, Shawn Heisey wrote: >> On 5/21/2015 6:21 AM, Modassar Ather wrote: >> > I am using Solr-5.1.0. I have an indexer class which invokes >> > cloudSolrClient.optimize(true, true, 1). My indexer exits after the >> > invocation of optimize and the optimization keeps on running in the >> > background. >> > Kindly let me know if it is per design and how can I make my indexer to >> > wait until the optimization is over. Is there a configuration/parameter I >> > need to set for the same. >> > >> > Please note that the same indexer with cloudSolrServer.optimize(true, true, >> > 1) on Solr-4.10 used to wait till the optimize was over before exiting. >> >> This is very odd, because I could not get HttpSolrServer to optimize in >> the background, even when that was what I wanted. >> >> I wondered if maybe the Cloud object behaves differently with regard to >> blocking until an optimize is finished ... except that there is no code >> for optimizing in CloudSolrClient at all ... so I don't know where the >> different behavior would actually be happening. > > A more important question is, why are you optimising? Generally it isn't > recommended anymore as it reduces the natural distribution of documents > amongst segments and makes future merges more costly. > > Upayavira
