[ https://issues.apache.org/jira/browse/SOLR-5580?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13858937#comment-13858937 ]
Mark Miller edited comment on SOLR-5580 at 12/30/13 5:23 PM: ------------------------------------------------------------- bq. was down was to avoid having another replica Yes, I know why you did it, I'm saying there are many problems with how you went about it. The entire reliance on the coreNodeName is incorrect. Like I said, even if you had said users can't specify it and ignored back compat, it can't be in solr.xml then. Your code only worked because it is a user setting that is persisted in solr.xml. Your goal is fine, the implementation is all wrong. While it could be corrected, I think it's much better to push on the collections api, rather than complicate what is now a simple mode that will eventually either become second class or be removed. We should not spend a lot of time making it do what it was not designed for from the start. The plan has always been the Collections API for this type of behavior. was (Author: markrmil...@gmail.com): bq. was down was to avoid having another replica Yes, I know why you did it, I'm saying there are many problems with how you went about it. The entire reliance on the coreNodeName is incorrect. Like I said, even if you had said users can't specify it and ignored back compat, it can't be in solr.xml then. Your code only worked because it is a user setting that is persisted in solr.xml. Your goal is fine, the implementation is all wrong. While it could be corrected, I think it's much better to push on the collections api, rather than complicated what is now a simple mode that will eventually either become second class or be removed. We should not spend a lot of time making it do what it was not designed for from the start. The plan has always been the Collections API for this type of behavior. > 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