That's not right. Which Solr versions are you on (question for both William and Chris)?
On Fri, Mar 21, 2014 at 8:07 AM, William Bell <billnb...@gmail.com> wrote: > Yeah. optimize() also used to come back immediately if the index was > already indexed. It just reopened the index. > > We uses to use that for cleaning up the old directories quickly. But now it > does another optimize() even through the index is already optimized. > > Very strange. > > > On Tue, Mar 18, 2014 at 11:30 AM, Chris Lu <chris...@gmail.com> wrote: > >> I wonder whether this is a known bug. In previous SOLR cloud versions, 4.4 >> or maybe 4.5, an explicit optimize(), without any parameters, it usually >> took 2 minutes for a 32 core cluster. >> >> However, in 4.6.1, the same call took about 1 hour. Checking the index >> modification time for each core shows 2 minutes gap if sorted. >> >> We are using a solrj client connecting to zookeeper. I found it is talking >> to a specific solr server A, and that server A is distributing the calls to >> all other solr servers. Here is the thread dump for this server A: >> >> at >> >> org.apache.solr.client.solrj.impl.HttpSolrServer.request(HttpSolrServer.java:395) >> at >> >> org.apache.solr.client.solrj.impl.HttpSolrServer.request(HttpSolrServer.java:199) >> at >> >> org.apache.solr.client.solrj.impl.ConcurrentUpdateSolrServer.request(ConcurrentUpdateSolrServer.java:293) >> at >> >> org.apache.solr.update.SolrCmdDistributor.submit(SolrCmdDistributor.java:226) >> at >> >> org.apache.solr.update.SolrCmdDistributor.distribCommit(SolrCmdDistributor.java:195) >> at >> >> org.apache.solr.update.processor.DistributedUpdateProcessor.processCommit(DistributedUpdateProcessor.java:1250) >> at >> >> org.apache.solr.handler.RequestHandlerUtils.handleCommit(RequestHandlerUtils.java:69) >> > > > > -- > Bill Bell > billnb...@gmail.com > cell 720-256-8076 -- Regards, Shalin Shekhar Mangar.
