[
https://issues.apache.org/jira/browse/SOLR-5872?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13938116#comment-13938116
]
Mark Miller commented on SOLR-5872:
-----------------------------------
Thanks Jessica - your comment is more along the lines of what you need to argue
to make a large change like this. Specifics.
I don't have time to write a detailed answer at the moment, but a lot of my
reservations are around the large refactoring that is being attempted to
support tons of collections. So far, I have not been super happy with a lot of
the work that has been done. Much of it seems hurried, existing tests have not
been beefed up in critical areas, new tests have been fairly minimal, and so
I'm likely to push back on many of these issues. We have too many stability
issues to tackle as it is. Abandoning code that has been getting hardened for
over a year now for a approach that was already abandoned should not be done
lightly.
If someone makes a thoughtful and clear argument with specifics and then makes
a thoughtful, well tested implementation, I'm much more likely to get on board.
I'll respond to the technical points when I get some time.
> 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
