[
https://issues.apache.org/jira/browse/SOLR-5872?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13938796#comment-13938796
]
Noble Paul edited comment on SOLR-5872 at 3/18/14 4:28 AM:
-----------------------------------------------------------
bq. I think if we decide to split out the clusterstate.json per collection,
that is the direction we should take
Yes, that is the plan
we would probably switch to that from 5.0 or something. But the challenge is to
offer a smother migration path. Till then we need a name to differentiate both
modes
* initially , users would be able to switch to that mode when creating a
collection (an opt In) SOLR-5473 does that
* offer an API to migrate to the new format SOLR-5756
* Make it the default format (from say 5.0)
* deprecate the old format
was (Author: noble.paul):
bq. I think if we decide to split out the clusterstate.json per collection,
that is the direction we should take
Yes, that is the plan
we would probably switch to that from 5.0 or something. But the challenge is to
offer a smother migration path.
* initially , users would be able to switch to that mode when creating a
collection (an opt In) SOLR-5473 does that
* offer an API to migrate to the new format SOLR-5756
* Make it the default format (from say 5.0)
* deprecate the old format
> Eliminate overseer queue
> -------------------------
>
> Key: SOLR-5872
> URL: https://issues.apache.org/jira/browse/SOLR-5872
> Project: Solr
> Issue Type: Improvement
> Components: SolrCloud
> Reporter: Noble Paul
> Assignee: Noble Paul
>
> The overseer queue is one of the busiest points in the entire system. The
> raison d'être of the queue is
> * Provide batching of operations for the main clusterstate,json so that
> state updates are minimized
> * Avoid race conditions and ensure order
> Now , as we move the individual collection states out of the main
> clusterstate.json, the batching is not useful anymore.
> Race conditions can easily be solved by using a compare and set in Zookeeper.
> The proposed solution is , whenever an operation is required to be performed
> on the clusterstate, the same thread (and of course the same JVM)
> # read the fresh state and version of zk node
> # construct the new state
> # perform a compare and set
> # if compare and set fails go to step 1
> This should be limited to all operations performed on external collections
> because batching would be required for others
--
This message was sent by Atlassian JIRA
(v6.2#6252)
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
