[ https://issues.apache.org/jira/browse/SOLR-12013?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16860497#comment-16860497 ]
Erick Erickson commented on SOLR-12013: --------------------------------------- *ZkStateReader.readConfigName* throws a really bogus error, which is causing *ClusterStatus.getClusterStatus* to throw an error rather than skip a collection that doesn't have an associated configset. ZkStateReader.readConfigName has this code: {code:java} String configPath = CONFIGS_ZKNODE + "/" + configName; if (!zkClient.exists(configPath, true)) { log.error("Specified config=[{}] does not exist in ZooKeeper at location=[{}]", configName, configPath); throw new ZooKeeperException(ErrorCode.SERVER_ERROR, "Specified config does not exist in ZooKeeper: " + configName); } else { log.debug("path=[{}] [{}]=[{}] specified config exists in ZooKeeper", configPath, CONFIGNAME_PROP, configName); } {code} But Clusterstatus.GetClusterStatus has this code: {code:java} try { String configName = zkStateReader.readConfigName(name); . . . } catch (SolrException e) { if (e.getCause() instanceof KeeperException.NoNodeException) { // skip this collection because the collection's znode has been deleted // which can happen during aggressive collection removal, see SOLR-10720 } else throw e; } {code} which can never be true since ZooKeeperException has nothing to do with NoNodeException. It makes no sense to me that when a znode is not present, we throw any kind of SolrException (the superclass of ZookeeperException) so I'll change *zkStateReader.readConfigName* to throw a NoNodeException I'll run the full test suite and correct any tests that rely on this behavior. It's vaguely possible this is responsible for some test failures given this comment: // skip this collection because the configset's znode has been deleted // which can happen during aggressive collection removal, see SOLR-10720 Throwing an NoNodeException does propagate to some other code, we'll see if it breaks other tests. > collections API CUSTERSTATUS command fails when collections have errors > ----------------------------------------------------------------------- > > Key: SOLR-12013 > URL: https://issues.apache.org/jira/browse/SOLR-12013 > Project: Solr > Issue Type: Bug > Components: SolrCloud > Affects Versions: 6.0, 7.0, 7.1, 7.2 > Reporter: Ben DeMott > Priority: Major > > CLUSTERSTATUS command can be given independent of a given collection. > http://localhost:8983/solr/admin/collections?action=CLUSTERSTATUS > I would expect that you can still inspect the status of a cluster even if a > single collection has failed, or is missing its configuration. > *Expected behavior*: all healthy collections status is returned, unhealthy > collections are either reported with a stacktrace in the response, reported > in a failure state, or are not present from the response. > For example, CLUSTERSTATUS fails when a collection config-set is missing from > ZooKeeper with: > {{*org.apache.solr.common.cloud.ZooKeeperException: Specified config does not > exist in ZooKeeper: config-set-name*}} > {{ *at > org.apache.solr.common.cloud.ZkStateReader.readConfigName(ZkStateReader.java:189)*}} > {{ at > org.apache.solr.handler.admin.ClusterStatus.getClusterStatus(ClusterStatus.java:141)}} > {{ at > org.apache.solr.handler.admin.CollectionsHandler$CollectionOperation.lambda$static$19(CollectionsHandler.java:649)}} > {{ at > org.apache.solr.handler.admin.CollectionsHandler$CollectionOperation.execute(CollectionsHandler.java:888)}} > {{ at > org.apache.solr.handler.admin.CollectionsHandler.invokeAction(CollectionsHandler.java:226)}} > {{ at > org.apache.solr.handler.admin.CollectionsHandler.handleRequestBody(CollectionsHandler.java:213)}} > {{ at > org.apache.solr.handler.RequestHandlerBase.handleRequest(RequestHandlerBase.java:173)}} > {{ at > org.apache.solr.servlet.HttpSolrCall.handleAdmin(HttpSolrCall.java:748)}} > {{ at > org.apache.solr.servlet.HttpSolrCall.handleAdminRequest(HttpSolrCall.java:729)}} > {{ at org.apache.solr.servlet.HttpSolrCall.call(HttpSolrCall.java:510)}} > {{ at > org.apache.solr.servlet.SolrDispatchFilter.doFilter(SolrDispatchFilter.java:347)}} > {{ at > org.apache.solr.servlet.SolrDispatchFilter.doFilter(SolrDispatchFilter.java:298)}} > {{ at > org.eclipse.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1691)}} > {{ at > org.eclipse.jetty.servlet.ServletHandler.doHandle(ServletHandler.java:582)}} > {{ at > org.eclipse.jetty.server.handler.ScopedHandler.handle(ScopedHandler.java:143)}} > {{ at > org.eclipse.jetty.security.SecurityHandler.handle(SecurityHandler.java:548)}} > {{ at > org.eclipse.jetty.server.session.SessionHandler.doHandle(SessionHandler.java:226)}} > {{ at > org.eclipse.jetty.server.handler.ContextHandler.doHandle(ContextHandler.java:1180)}} > {{ at > org.eclipse.jetty.servlet.ServletHandler.doScope(ServletHandler.java:512)}} > {{ at > org.eclipse.jetty.server.session.SessionHandler.doScope(SessionHandler.java:185)}} > {{ at > org.eclipse.jetty.server.handler.ContextHandler.doScope(ContextHandler.java:1112)}} > {{ at > org.eclipse.jetty.server.handler.ScopedHandler.handle(ScopedHandler.java:141)}} > {{ at > org.eclipse.jetty.server.handler.ContextHandlerCollection.handle(ContextHandlerCollection.java:213)}} > {{ at > org.eclipse.jetty.server.handler.HandlerCollection.handle(HandlerCollection.java:119)}} > {{ at > org.eclipse.jetty.server.handler.HandlerWrapper.handle(HandlerWrapper.java:134)}} > {{ at > org.eclipse.jetty.rewrite.handler.RewriteHandler.handle(RewriteHandler.java:335)}} > {{ at > org.eclipse.jetty.server.handler.HandlerWrapper.handle(HandlerWrapper.java:134)}} > {{ at org.eclipse.jetty.server.Server.handle(Server.java:534)}} > {{ at org.eclipse.jetty.server.HttpChannel.handle(HttpChannel.java:320)}} > {{ at > org.eclipse.jetty.server.HttpConnection.onFillable(HttpConnection.java:251)}} > {{ at > org.eclipse.jetty.io.AbstractConnection$ReadCallback.succeeded(AbstractConnection.java:273)}} > {{ at org.eclipse.jetty.io.FillInterest.fillable(FillInterest.java:95)}} > {{ at > org.eclipse.jetty.io.SelectChannelEndPoint$2.run(SelectChannelEndPoint.java:93)}} > {{ at > org.eclipse.jetty.util.thread.strategy.ExecuteProduceConsume.executeProduceConsume(ExecuteProduceConsume.java:303)}} > {{ at > org.eclipse.jetty.util.thread.strategy.ExecuteProduceConsume.produceConsume(ExecuteProduceConsume.java:148)}} > {{ at > org.eclipse.jetty.util.thread.strategy.ExecuteProduceConsume.run(ExecuteProduceConsume.java:136)}} > {{ at > org.eclipse.jetty.util.thread.QueuedThreadPool.runJob(QueuedThreadPool.java:671)}} > {{ at > org.eclipse.jetty.util.thread.QueuedThreadPool$2.run(QueuedThreadPool.java:589)}} > {{ at java.lang.Thread.run(Thread.java:745)}} > -- This message was sent by Atlassian JIRA (v7.6.3#76005) --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org