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
