[
https://issues.apache.org/jira/browse/SOLR-5473?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14050656#comment-14050656
]
Shalin Shekhar Mangar commented on SOLR-5473:
---------------------------------------------
Mark, we have to revert it if your -1 stands. But we have already done it once
and it hasn't been very productive because when it comes to your biggest
objection of coupling ZkStateReader and ClusterState then neither you nor Noble
or I had a suggestion. If we move it to a branch then again we will be in the
same place a month down the line since as you say you don't have time to help
with it.
bq. This is also still not "Make one state.json per collection", but a bunch of
issues all connected to that.
Yes but there's no point of have a state per collection without those other
changes. Tim wrote very eloquently about what's changed in terms of nodes
watching the state and why we think it is necessary.
Noble said earlier that these hacks in the API were put in place to support
back-compat. Having looked at this patch in depth more times than I can
remember over the past few months, I agree with Noble that it is difficult to
do without it. This API is definitely not the API we want for Solr 5 and I
completely agree with you on that. We can refactor and do away with the
ClusterState completely on trunk (and we intend to do that in future) but
before we that, a back-compatible version of this change needs to land on
branch_4x.
It is crazy that it takes a commit to get your attention (and veto!) when
things can be resolved via discussion and collaboration. Tim and I have been
reviewing this patch and we shall continue to work with Noble on improving it
but I am afraid that it might be unproductive again because after three
committers are comfortable with the approach and commit it to trunk, you veto
it without any constructive suggestions on actually improving the APIs.
IMO, we should continue to iterate on trunk for a while (at least we have
jenkins there) and get the APIs right as we want them for Solr 5 and then
figure out how move it to branch_4x in a back-compatible and hopefully non-ugly
way.
> Make one state.json per collection
> ----------------------------------
>
> Key: SOLR-5473
> URL: https://issues.apache.org/jira/browse/SOLR-5473
> Project: Solr
> Issue Type: Sub-task
> Components: SolrCloud
> Reporter: Noble Paul
> Assignee: Noble Paul
> Fix For: 5.0
>
> Attachments: SOLR-5473-74 .patch, SOLR-5473-74.patch,
> SOLR-5473-74.patch, SOLR-5473-74.patch, SOLR-5473-74.patch,
> SOLR-5473-74.patch, SOLR-5473-74.patch, SOLR-5473-74.patch,
> SOLR-5473-74.patch, SOLR-5473-74.patch, SOLR-5473-74.patch,
> SOLR-5473-74.patch, SOLR-5473-74.patch, SOLR-5473-74.patch,
> SOLR-5473-74.patch, SOLR-5473-74.patch, SOLR-5473-74.patch,
> SOLR-5473-74.patch, SOLR-5473-74.patch, SOLR-5473-74.patch,
> SOLR-5473-74.patch, SOLR-5473-74.patch, SOLR-5473-74.patch,
> SOLR-5473-74.patch, SOLR-5473-74.patch, SOLR-5473-74.patch,
> SOLR-5473-74.patch, SOLR-5473-74.patch, SOLR-5473-74.patch,
> SOLR-5473-74.patch, SOLR-5473-74.patch, SOLR-5473-configname-fix.patch,
> SOLR-5473.patch, SOLR-5473.patch, SOLR-5473.patch, SOLR-5473.patch,
> SOLR-5473.patch, SOLR-5473.patch, SOLR-5473.patch, SOLR-5473.patch,
> SOLR-5473.patch, SOLR-5473.patch, SOLR-5473.patch, SOLR-5473.patch,
> SOLR-5473.patch, SOLR-5473.patch, SOLR-5473.patch, SOLR-5473.patch,
> SOLR-5473.patch, SOLR-5473.patch, SOLR-5473_undo.patch,
> ec2-23-20-119-52_solr.log, ec2-50-16-38-73_solr.log
>
>
> As defined in the parent issue, store the states of each collection under
> /collections/collectionname/state.json node
--
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
