lucene-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Mark Miller (JIRA)" <j...@apache.org>
Subject [jira] [Commented] (SOLR-5473) Make one state.json per collection
Date Thu, 24 Apr 2014 17:27:21 GMT

    [ https://issues.apache.org/jira/browse/SOLR-5473?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13979983#comment-13979983
] 

Mark Miller commented on SOLR-5473:
-----------------------------------

Thank you.

bq. The idea of splitting the clusterstate.json itself

I have no problem with this.

bq. The external interface

I've already gone into a lot of the points. We can dig more into what is not clear from the
above.

bq. The idea of selectively watching states 

The is also probably fine, though I'm not sure it's right to change it by default, and I'm
not sure it should be so tied into "The idea of splitting the clusterstate.json itself". Breaking
things into parts makes it easier to digest and build and document properly.

bq. The API's which are 'undesirable'

I go into that above - again, I can answer specific questions. Look at all the get collection
methods - look at all the crazy different behaviors depending on what you call - look at the
lack of documentation. Future developers will be hopelessly lost. Anyway, I've brought up
enough issues above to get started on understanding what some of the current problems are.
If you look at the API's now, you can see it's just a mess. It all seems to work okay, and
that is good, but it needs to be done thoughtfully as well, and I don't think anyone can easily
deal with API's as they are.

bq. I would like to work towards a consensus and resolve this

I'm sure that can be done - I do think there is a lot to do and it's too core to rush it in.

I think a good approach would be too break it up and do things in discrete parts - eg splitting
up clusterstate.json seems independent of a lot of these other changes. That part is not the
most important part though - mostly, we have to get to some well documented API's that make
sense - especially on 5x where we don't even necessarily have back compat concerns. 

> 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.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,
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