lucene-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Noble Paul (JIRA)" <j...@apache.org>
Subject [jira] [Comment Edited] (SOLR-5580) NPE when create a core with both explicite shard and coreNodeName
Date Mon, 30 Dec 2013 16:17:53 GMT

    [ 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-unsubscribe@lucene.apache.org
For additional commands, e-mail: dev-help@lucene.apache.org


Mime
View raw message