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 00:47:21 GMT

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

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

{code}
      if(collection !=null && collection.isExternal()  ){
        log.info("Registering watch for external collection {}",cd.getCloudDescriptor().getCollectionName());
        zkStateReader.addCollectionWatch(cd.getCloudDescriptor().getCollectionName());
      }
{code}

That is the part I'm curious about - I don't know what internal, external means.

Here is what what makes sense to me for a JIRA issue named "Make one state.json per collection"
and the previous discussions we have had.

Storing all collections in cluster.json will be considered clusterstate stateFormat=1.
Storing each collection in it's own cluster.json will be considered clusterstate stateFormat=2.

I looked at your patch and it still leaves tons of internal, external stuff. It's all very,
very confusing. If I had reviewed this before it was committed, I would say it's not ready.

In which cases do we makes watches? In which cases don't we? I would oppose changing the default
behavior to stop using watches, but without spending a lot of time with the code, it's not
very clear how the new stuff works vs the old.

Some notes on your new patch:

In your patch you have made the change:
{code}
-        if (coll.isExternal()) {
+        if (coll.getStateVersion()>1) {
{code}

Why do we have getStateVersion and stateFormat? Why > 1 and not =2?

bq. log.info("Creating collection with stateFormat=3: " + collectionName);

stateFormat=3?

Back to this issue overall:

This adds a lot of confusing methods and uses a lot of confusing terminology, non of which
is defined. Most of the new methods are also not documented and there are few comments to
help explain what is going on in the new stuff at a high level. I think this really muddles
a bunch of user API's.

I'd like to understand more about the watcher situation, but I think there is still a lot
of clean up to do here and I'll look at making a patch next week.


> 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