Hendrik: Historically in 4.x, there was code that would reconstruct the clusterstate.json code. So you would see "deleted" collections come back. One scenario was:
- Have a Solr node offline that had a replica for a collection. - Delete that collection - Bring the node back - It would register itself in clusterstate.json. So my guess is that something like this is going on and you're getting a clusterstate.json that's reconstructed (and possibly not complete). You can avoid this by specifying legacyCloud=false clusterprop Kind of a shot in the dark... Erick On Wed, Jan 4, 2017 at 11:12 AM, Hendrik Haddorp <hendrik.hadd...@gmx.net> wrote: > You are right, the code looks like it. But why did I then see collection > data in the clusterstate.json file? If version 1 is not used I would > assume that no data ends up in there. When explicitly setting the state > format 2 the system seemed to behave differently. And if the code always > uses version 2 shouldn't the default in that line be changed accordingly? > > On 04/01/17 16:41, Shalin Shekhar Mangar wrote: >> Actually the state format defaults to 2 since many releases (all of >> 6.x at least). This default is enforced in CollectionsHandler much >> before the code in ClusterStateMutator is executed. >> >> On Wed, Jan 4, 2017 at 6:16 PM, Hendrik Haddorp <hendrik.hadd...@gmx.net> >> wrote: >>> Hi, >>> >>> in >>> solr-6.3.0/solr/core/src/java/org/apache/solr/cloud/overseer/ClusterStateMutator.java >>> there is the following code starting line 107: >>> >>> //TODO default to 2; but need to debug why BasicDistributedZk2Test fails >>> early on >>> String znode = message.getInt(DocCollection.STATE_FORMAT, 1) == 1 ? null >>> : ZkStateReader.getCollectionPath(cName); >>> >>> Any if that will be changed to default to version 2 anytime soon? >>> >>> thanks, >>> Hendrik >> >> >
