You are viewing a plain text version of this content. The canonical link for it is here.
Posted to solr-user@lucene.apache.org by Chris Lu <ch...@gmail.com> on 2014/03/18 18:30:26 UTC
solr cloud distributed optimize() becomes serialized
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)
Re: solr cloud distributed optimize() becomes serialized
Posted by Shalin Shekhar Mangar <sh...@gmail.com>.
Found it - https://issues.apache.org/jira/browse/LUCENE-5481
On Fri, Mar 21, 2014 at 8:11 PM, Mark Miller <ma...@gmail.com> 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.walters@answers.com) wrote:
>
> I've seen this on 4.6.
>
> Thanks,
> Greg
>
> On Mar 20, 2014, at 11:58 PM, Shalin Shekhar Mangar <sh...@gmail.com> 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 <bi...@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 <ch...@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
>>> billnbell@gmail.com
>>> cell 720-256-8076
>>
>>
>>
>> --
>> Regards,
>> Shalin Shekhar Mangar.
>
--
Regards,
Shalin Shekhar Mangar.
Re: solr cloud distributed optimize() becomes serialized
Posted by Mark Miller <ma...@gmail.com>.
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.walters@answers.com) wrote:
I've seen this on 4.6.
Thanks,
Greg
On Mar 20, 2014, at 11:58 PM, Shalin Shekhar Mangar <sh...@gmail.com> 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 <bi...@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 <ch...@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
>> billnbell@gmail.com
>> cell 720-256-8076
>
>
>
> --
> Regards,
> Shalin Shekhar Mangar.
Re: solr cloud distributed optimize() becomes serialized
Posted by Greg Walters <gr...@answers.com>.
I've seen this on 4.6.
Thanks,
Greg
On Mar 20, 2014, at 11:58 PM, Shalin Shekhar Mangar <sh...@gmail.com> 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 <bi...@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 <ch...@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
>> billnbell@gmail.com
>> cell 720-256-8076
>
>
>
> --
> Regards,
> Shalin Shekhar Mangar.
Re: solr cloud distributed optimize() becomes serialized
Posted by Shalin Shekhar Mangar <sh...@gmail.com>.
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 <bi...@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 <ch...@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
> billnbell@gmail.com
> cell 720-256-8076
--
Regards,
Shalin Shekhar Mangar.
Re: solr cloud distributed optimize() becomes serialized
Posted by William Bell <bi...@gmail.com>.
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 <ch...@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
billnbell@gmail.com
cell 720-256-8076