[
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: [email protected]):
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: [email protected]
For additional commands, e-mail: [email protected]
