Found it - https://issues.apache.org/jira/browse/LUCENE-5481
On Fri, Mar 21, 2014 at 8:11 PM, Mark Miller wrote:
> Recently fixed in Lucene - should be able to find the issue if you dig a
> little.
> --
> Mark Miller
> about.me/markrmiller
>
> On March 21, 2014 at 10:25:56 AM, Greg Walters (greg
Recently fixed in Lucene - should be able to find the issue if you dig a little.
--
Mark Miller
about.me/markrmiller
On March 21, 2014 at 10:25:56 AM, Greg Walters (greg.walt...@answers.com) wrote:
I've seen this on 4.6.
Thanks,
Greg
On Mar 20, 2014, at 11:58 PM, Shalin Shekhar Mangar
I've seen this on 4.6.
Thanks,
Greg
On Mar 20, 2014, at 11:58 PM, Shalin Shekhar Mangar
wrote:
> 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 wrote:
>> Yeah. optimize() also used to come back immed
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 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 u
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 a
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 m
