[jira] [Comment Edited] (SOLR-5580) NPE when create a core with both explicite shard and coreNodeName
[
https://issues.apache.org/jira/browse/SOLR-5580?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13858900#comment-13858900
]
Noble Paul edited comment on SOLR-5580 at 12/30/13 4:17 PM:
bq.It's just a matter of opinion
Yes, you are right. the point is , I think people don't really have to think
that replicas have a name , they just need to have enough replicas for a given
slice.
bq.I don't believe that - it should be fine to still have a command that
removes a replica from the clusterstate.
The problem is that, If I removed a replica from clusterstate and then the core
came up, What is the desired behavior? register the core or unload the core?
bq.Then perhaps they should not be implemented and this energy is better spent
working towards a fully functional Collections API.
SOLR-5310 is a step towards a fully functional collections API. The use case
is, A node went down and I don't need to replace it with another node because I
have enough replicas. Now I need to clean up the clusterstate .Currently there
is no way to achieve it
bq.uh...yes it is used...
I',m sorry, I meant it is not used anywhere BY THE USER
My intent was not to break backcompat . But it happened because I didn't know
this particular usecase. Let us see what is the best solution for this? Let us
answer a few questions to ourselves
* If we are designing the system today which way would you choose? a
deletereplica API or a create core API to 'replace' a core. So what is the way
forward?
* implement deletereplica API , but make the clusterstate slightly ugly for
backcompat
was (Author: noble.paul):
bq.It's just a matter of opinion
Yes, you are right. the point is , I think people don't really have to think
that replicas have a name , they just need to have enough replicas for a given
slice.
bq.I don't believe that - it should be fine to still have a command that
removes a replica from the clusterstate.
The problem is that, If I removed a replica from clusterstate and then the core
came up, What is the desired behavior? register the core or unload the core?
bq.Then perhaps they should not be implemented and this energy is better spent
working towards a fully functional Collections API.
SOLR-5310 is a step towards a fully functional collections API. The use case
is, A node went down and I don't need to replace it with another node because I
have enough replicas. Now I need to clean up the clusterstate .Currently there
is no way to achieve it
bq.uh...yes it is used...
I',m sorry, I meant it is not used anywhere BY THE USER
My intent was not to break backcompat . But it happened because I didn't know
this particular usecase.Let us see what is the best solution for this? Let us
answer a few questions to ourselves
* If we are designing the system today which way would you choose? a
deletereplica API or a create core API to 'replace' a core
* implement deletereplica API , but make the clusterstate slightly ugly for
backward compatibility
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
[jira] [Comment Edited] (SOLR-5580) NPE when create a core with both explicite shard and coreNodeName
[
https://issues.apache.org/jira/browse/SOLR-5580?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=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
[jira] [Comment Edited] (SOLR-5580) NPE when create a core with both explicite shard and coreNodeName
[
https://issues.apache.org/jira/browse/SOLR-5580?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13858970#comment-13858970
]
Mark Miller edited comment on SOLR-5580 at 12/30/13 6:27 PM:
-
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? Now 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.
was (Author: markrmil...@gmail.com):
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;
}
}
[jira] [Comment Edited] (SOLR-5580) NPE when create a core with both explicite shard and coreNodeName
[
https://issues.apache.org/jira/browse/SOLR-5580?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13859338#comment-13859338
]
Noble Paul edited comment on SOLR-5580 at 12/31/13 5:29 AM:
Mark,
This issue is about an NPE . If we fix this NPE we should be good to go. The
wholesale reverting of SOLR-5311 is beyond the scope of this issue. SOLR-5311
has already been released in 4.6 and reverting that code would be a regression
in 4.6.1.
We can fix the NPE right away and make the core admin API work and this can be
closed. I can take care of that right away. If we need a discussion over how
the implementation of SOLR-5311 should be, it can be done after reopening
SOLR-5311
was (Author: noble.paul):
Mark,
This issue is about an NPE . If we fix this NPE we should be good to go. The
wholesale reverting of SOLR-5311 is beyond the scope of this issue. We can fix
the NPE right away and make the core admin API work and this can be closed. I
can take care of that right away.
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
[jira] [Comment Edited] (SOLR-5580) NPE when create a core with both explicite shard and coreNodeName
[
https://issues.apache.org/jira/browse/SOLR-5580?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13858841#comment-13858841
]
Noble Paul edited comment on SOLR-5580 at 12/30/13 2:51 PM:
Yes , this is expected to fail.
But why would anyone create a core with explicit coreNodeName. I wanted that
case to be eliminated.
The idea is to only create the coreNodeName at the Overseer
was (Author: noble.paul):
Yes , this is expected to fail.
But why would anyone create a core with explicit coreNodeName. I wanted that
case to be eliminated.
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
