lucene-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Shalin Shekhar Mangar (JIRA)" <j...@apache.org>
Subject [jira] [Commented] (SOLR-6554) Speed up overseer operations for collections with stateFormat > 1
Date Mon, 01 Dec 2014 19:11:13 GMT

    [ https://issues.apache.org/jira/browse/SOLR-6554?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14230266#comment-14230266
] 

Shalin Shekhar Mangar commented on SOLR-6554:
---------------------------------------------

bq. What kind of confidence do we have for stateFormat = 2 now? 

I am pretty confident that it works and works well. But the client side needs a fix before
5.0 -- SOLR-6521.

bq. It would really be nice to drop 1 from 5x rather than deal with both for a full major
version again.

I agree but how do we drop 1? I haven't thought through the migration process. It would probably
need us to write the state to both places for one Solr release to auto-convert. Otherwise
an upgrade would require down-time. We could definitely use stateFormat=2 as the default in
5.0 as it is already as performant as stateFormat=1 for the single collection use-case.

> Speed up overseer operations for collections with stateFormat > 1
> -----------------------------------------------------------------
>
>                 Key: SOLR-6554
>                 URL: https://issues.apache.org/jira/browse/SOLR-6554
>             Project: Solr
>          Issue Type: Improvement
>          Components: SolrCloud
>    Affects Versions: 5.0, Trunk
>            Reporter: Shalin Shekhar Mangar
>         Attachments: SOLR-6554-batching-refactor.patch, SOLR-6554-batching-refactor.patch,
SOLR-6554-batching-refactor.patch, SOLR-6554-batching-refactor.patch, SOLR-6554.patch, SOLR-6554.patch,
SOLR-6554.patch, SOLR-6554.patch, SOLR-6554.patch, SOLR-6554.patch, SOLR-6554.patch, SOLR-6554.patch
>
>
> Right now (after SOLR-5473 was committed), a node watches a collection only if stateFormat=1
or if that node hosts at least one core belonging to that collection.
> This means that a node which is the overseer operates on all collections but watches
only a few. So any read goes directly to zookeeper which slows down overseer operations.
> Let's have the overseer node watch all collections always and never remove those watches
(except when the collection itself is deleted).



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@lucene.apache.org
For additional commands, e-mail: dev-help@lucene.apache.org


Mime
View raw message