[
https://issues.apache.org/jira/browse/SOLR-5872?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13938498#comment-13938498
]
Mark Miller commented on SOLR-5872:
-----------------------------------
{noformat}
People suggest new changes to the system when /where they think it is required.
It is important that we counter suggestions on their own merits/demerits.
{noformat}
Of course - and given this issue as presented, as I said "I'm not fully sold on
this yet." The other background I gave also applies to all of these issues. We
won't just rip out tons of code and replace it just because someone has
identified an issue and proposed a solution. The bar for this type of change
should be high. Given the history of these changes, I'm going to have to be
sold more than if the history was better. Each contributor is also judged on
their merit - what have they contributed so far, what's the quality of their
contributions, how much are they helping with test fails, etc. The more merit
you have on SolrCloud, the more likely these large scale refactorings will
receive support.
{noformat}
As developers, we need to guide/handhold the users who are pushing the envelope
. At some point when we develop enough confidence we can integrate it into the
product itself .
{noformat}
We don't necessarily need to hold hands - we need to take that on a case by
case basis. We need to walk before we can run. We should probably jog before we
run as well.
It's an issue by issue thing though, and Jessica has already begun providing a
case for looking at this.
bq. At some point when we develop enough confidence we can integrate it into
the product itself .
I've heard that before and I'm not totally sold that's how things will play
out. Certainly they would not play out that way without some push back on these
issues IMO.
> 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
