[
https://issues.apache.org/jira/browse/SOLR-6554?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14229085#comment-14229085
]
Shalin Shekhar Mangar commented on SOLR-6554:
---------------------------------------------
bq. IMHO multi write is not really useful . The reason for batching is to
minimize the number of listeners fired and the number of clusterstate updates
in the listener nodes. So, whether you write those nodes in multiple ops or in
a single op does not really matter
I think you may be right but it is worth testing out. The multi write will
reduce writes to ZK and maybe reduce the number of watcher fires under the
right conditions (interleaved messages for two different collections). I'll do
a quick test to see if it helps.
> 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.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-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
