[ https://issues.apache.org/jira/browse/SOLR-5580?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13858970#comment-13858970 ]
Mark Miller commented on SOLR-5580: ----------------------------------- bq.I agree with you . But what is the harm in making the coreNodeName editable? If he is sure about what he is doing , it will work. If he is fiddling with stuff any of those properties can screw up his system. I really can't see the difference between someone editing collection, shard, or coreNodeName It *is* currently editable. The way you did things, you would need it to not be editable. So no way it should be in solr.xml. You can configure a new core in solr.xml and set a shard id and a collection - but now you are going to say you can't set some of those settings (coreNodeName), we are just storing them there internally and it's not for you to preconfigure or edit? No we have some special config in solr.xml that is not for users when everything else is? No way, -1. bq. If and when we are ready , how do you plan to make the switch? Can we introduce the switch right away, so that the users who want the new way can go that way. We will need to support non Collections API for some time. For the Collections API, its just going to become more capable - if it requires it, some of those capabilities will require turning on new options if you are using old config. It will all be pretty easy, other than when and if we drop the non Collections API support entirely. > NPE when create a core with both explicite shard and coreNodeName > ------------------------------------------------------------------ > > Key: SOLR-5580 > URL: https://issues.apache.org/jira/browse/SOLR-5580 > Project: Solr > Issue Type: Bug > Affects Versions: 4.6 > Environment: OS:Red Hat Enterprise Linux Server release 6.4 (Santiago) > Software:solr 4.6, > jdk:OpenJDK Runtime Environment (rhel-2.3.4.1.el6_3-x86_64) > OpenJDK 64-Bit Server VM (build 23.2-b09, mixed mode) > Reporter: YouPeng Yang > Assignee: Mark Miller > Labels: core > Fix For: 5.0, 4.7, 4.6.1 > > Original Estimate: 0.5h > Remaining Estimate: 0.5h > > In class org.apache.solr.cloud.Overseer the Line 360: > --------------------------------------------------------------------- > if (sliceName !=null && collectionExists && > !"true".equals(state.getCollection(collection).getStr("autoCreated"))) { > Slice slice = state.getSlice(collection, sliceName); > if (slice.getReplica(coreNodeName) == null) { > log.info("core_deleted . Just return"); > return state; > } > } > --------------------------------------------------------------------- > the slice needs to be checked null .because when create a new core with both > explicite shard and coreNodeName, the state.getSlice(collection, sliceName) > may return a null.So it needs to be checked ,or there will be an > NullpointException > --------------------------------------------------------------------- > if (sliceName !=null && collectionExists && > !"true".equals(state.getCollection(collection).getStr("autoCreated"))) { > Slice slice = state.getSlice(collection, sliceName); > if (slice != null && slice.getReplica(coreNodeName) == null) { > log.info("core_deleted . Just return"); > return state; > } > } > --------------------------------------------------------------------- -- This message was sent by Atlassian JIRA (v6.1.5#6160) --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org