lucene-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Shalin Shekhar Mangar (JIRA)" <j...@apache.org>
Subject [jira] [Commented] (SOLR-5473) Make one state.json per collection
Date Wed, 02 Jul 2014 20:18:26 GMT

    [ 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-unsubscribe@lucene.apache.org
For additional commands, e-mail: dev-help@lucene.apache.org


Mime
View raw message