[
https://issues.apache.org/jira/browse/SOLR-5580?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=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 && 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
