I have this code in my SolrJ program:
LOG.info("{}: background optimizing", logPrefix);
myOptimizeSolrClient.optimize(myName, false, false);
elapsedMillis = (System.nanoTime() - startNanos) / 1000000;
LOG.info("{}: Background optimize completed, elapsed={}", logPrefix,
elapsedMillis);
This is what I get when this code runs. I expected it to return
immediately, but it took 49 seconds:
INFO - 2016-11-08 15:10:56.316; 409; shard.c.inc.inclive.optimize;
shard.c.inc.inclive: Background optimize completed, elapsed=49339
I'm using SolrJ 5.5.3, and the SolrClient object is HttpSolrClient. I
have not tried 6.x versions. The server that this is talking to is
5.3.2-SNAPSHOT.
I found this in solr.log:
2016-11-08 15:10:56.315 INFO (qtp1164175787-708968) [ x:inclive]
org.apache.solr.update.processor.LogUpdateProcessor [inclive]
webapp=/solr path=/update
params={optimize=true&maxSegments=1&waitSearcher=true&wt=javabin&version=2}
{optimize=} 0 49338
It looks like waitSearcher is not being set properly by the SolrJ code.
I could not see any obvious problem in the master branch, which I
realize is not the same as the 5.5 code I'm running.
I did try the request manually, both with waitSearcher set to true and
to false, and in both cases, the request DID wait until the optimize was
finished before it returned a response. So even if the SolrJ problem is
fixed, Solr itself will not work the way I'm expecting. Is it correct
to expect an immediate return for optimize when waitSearcher is false?
I am not in a position to try this in 6.x versions. Is there anyone out
there who does have a 6.x index they can try it on, see if it's still a
problem?
Thanks,
Shawn
