[ https://issues.apache.org/jira/browse/SOLR-14774?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17183441#comment-17183441 ]
Tomas Eduardo Fernandez Lobbe commented on SOLR-14774: ------------------------------------------------------ This Jira addresses two bugs: 1) [The documentation|https://lucene.apache.org/solr/guide/8_6/implicit-requesthandlers.html#admin-handlers] claims that this can be accessed via {{solr/<core>/admin/health}}, however, this isn't right. If you look at the code, you'll see that implicit plugins for the SolrCore are either created with a constructor that receives the SolrCore or with a parameterless constructor. HealthCheckHandler is supposed to be a top level handler, so it doesn't have a constructor that receives a SolrCore, so it'll be created (for the SolrCore) with a parameterless constructor. Now, if you look at the first line in the {{handleRequestBody}} method, you'll see that this will never work: https://github.com/apache/lucene-solr/blob/master/solr/core/src/java/org/apache/solr/handler/admin/HealthCheckHandler.java#L95. One alternative is to create a constructor that receives the SolrCore, and then get the coreContainer from there, but it doesn't make sense, since every core would be checking the exact same thing. Also, for a in-core healthcheck we have the "ping" request handler now, which is core-specific and has a different set of features. 2) This handler was created with the intention of being pluggable. If you see the [NodeConfig|https://github.com/apache/lucene-solr/blob/master/solr/core/src/java/org/apache/solr/core/NodeConfig.java#L199], you'll see that it has a method to get the handler class from {{solr.xml}}. And if you see [CoreContainer|https://github.com/apache/lucene-solr/blob/master/solr/core/src/java/org/apache/solr/core/CoreContainer.java#L182], you'll see that it has a {{healthCheckHandler}} field, that is never initialized or used. Looks like somewhere in the commits for SOLR-11126 this was done by mistake. Let me know if you still have concernes > HealthCheckHandler shouldn't be an implicit SolrCore level handler and should > be configurable > --------------------------------------------------------------------------------------------- > > Key: SOLR-14774 > URL: https://issues.apache.org/jira/browse/SOLR-14774 > Project: Solr > Issue Type: Improvement > Security Level: Public(Default Security Level. Issues are Public) > Reporter: Tomas Eduardo Fernandez Lobbe > Priority: Major > Time Spent: 40m > Remaining Estimate: 0h > > While trying to use the HealthCheckHandler I noticed that: > * CoreContainer has some logic to read config from {{solr.xml}}, however, > this is never used, and the handler is constructed explicitly inside > {{InfoHandler}}. This means you can't plugin a different implementation. > * Also noticed that it was added as an implicit plugin to the {{SolrCore}}. > which means one could access the handler like > {{/<collection-or-core>/admin/health}}, however, this will never work, since > it uses a parameterless constructor, which leaves the handler in an invalid > state [1]. I honestly don't know why it's being added to the {{SolrCore}}, > this is supposed to be a node level handler, and for SolrCore one could use > the {{PingRequestHandler}} > > [1] > {noformat} > 2020-08-21 21:14:06.094 ERROR (qtp599782425-18) [c:test s:shard1 r:core_node4 > x:test_shard1_replica_n2] o.a.s.s.HttpSolrCall > null:org.apache.solr.common.SolrException: CoreContainer is either not > initialized or shutting down > at > org.apache.solr.handler.admin.HealthCheckHandler.handleRequestBody(HealthCheckHandler.java:96) > at > org.apache.solr.handler.RequestHandlerBase.handleRequest(RequestHandlerBase.java:214) > at org.apache.solr.core.SolrCore.execute(SolrCore.java:2606) > at org.apache.solr.servlet.HttpSolrCall.execute(HttpSolrCall.java:812) > at org.apache.solr.servlet.HttpSolrCall.call(HttpSolrCall.java:588) > at > org.apache.solr.servlet.SolrDispatchFilter.doFilter(SolrDispatchFilter.java:415) > at > org.apache.solr.servlet.SolrDispatchFilter.doFilter(SolrDispatchFilter.java:345) > at > org.eclipse.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1596) > at > org.eclipse.jetty.servlet.ServletHandler.doHandle(ServletHandler.java:545) > at > org.eclipse.jetty.server.handler.ScopedHandler.handle(ScopedHandler.java:143) > at > org.eclipse.jetty.security.SecurityHandler.handle(SecurityHandler.java:590) > at > org.eclipse.jetty.server.handler.HandlerWrapper.handle(HandlerWrapper.java:127) > at > org.eclipse.jetty.server.handler.ScopedHandler.nextHandle(ScopedHandler.java:235) > at > org.eclipse.jetty.server.session.SessionHandler.doHandle(SessionHandler.java:1610) > at > org.eclipse.jetty.server.handler.ScopedHandler.nextHandle(ScopedHandler.java:233) > at > org.eclipse.jetty.server.handler.ContextHandler.doHandle(ContextHandler.java:1300) > at > org.eclipse.jetty.server.handler.ScopedHandler.nextScope(ScopedHandler.java:188) > at > org.eclipse.jetty.servlet.ServletHandler.doScope(ServletHandler.java:485) > at > org.eclipse.jetty.server.session.SessionHandler.doScope(SessionHandler.java:1580) > at > org.eclipse.jetty.server.handler.ScopedHandler.nextScope(ScopedHandler.java:186) > at > org.eclipse.jetty.server.handler.ContextHandler.doScope(ContextHandler.java:1215) > at > org.eclipse.jetty.server.handler.ScopedHandler.handle(ScopedHandler.java:141) > at > org.eclipse.jetty.server.handler.ContextHandlerCollection.handle(ContextHandlerCollection.java:221) > at > org.eclipse.jetty.server.handler.InetAccessHandler.handle(InetAccessHandler.java:177) > at > org.eclipse.jetty.server.handler.HandlerCollection.handle(HandlerCollection.java:146) > at > org.eclipse.jetty.server.handler.HandlerWrapper.handle(HandlerWrapper.java:127) > at > org.eclipse.jetty.rewrite.handler.RewriteHandler.handle(RewriteHandler.java:322) > at > org.eclipse.jetty.server.handler.HandlerWrapper.handle(HandlerWrapper.java:127) > at org.eclipse.jetty.server.Server.handle(Server.java:500) > at > org.eclipse.jetty.server.HttpChannel.lambda$handle$1(HttpChannel.java:383) > at org.eclipse.jetty.server.HttpChannel.dispatch(HttpChannel.java:547) > at org.eclipse.jetty.server.HttpChannel.handle(HttpChannel.java:375) > at > org.eclipse.jetty.server.HttpConnection.onFillable(HttpConnection.java:273) > at > org.eclipse.jetty.io.AbstractConnection$ReadCallback.succeeded(AbstractConnection.java:311) > at org.eclipse.jetty.io.FillInterest.fillable(FillInterest.java:103) > at > org.eclipse.jetty.io.ChannelEndPoint$2.run(ChannelEndPoint.java:117) > at > org.eclipse.jetty.util.thread.strategy.EatWhatYouKill.runTask(EatWhatYouKill.java:336) > at > org.eclipse.jetty.util.thread.strategy.EatWhatYouKill.doProduce(EatWhatYouKill.java:313) > at > org.eclipse.jetty.util.thread.strategy.EatWhatYouKill.tryProduce(EatWhatYouKill.java:171) > at > org.eclipse.jetty.util.thread.strategy.EatWhatYouKill.run(EatWhatYouKill.java:129) > at > org.eclipse.jetty.util.thread.ReservedThreadExecutor$ReservedThread.run(ReservedThreadExecutor.java:375) > at > org.eclipse.jetty.util.thread.QueuedThreadPool.runJob(QueuedThreadPool.java:806) > at > org.eclipse.jetty.util.thread.QueuedThreadPool$Runner.run(QueuedThreadPool.java:938) > at java.base/java.lang.Thread.run(Thread.java:834) {noformat} -- This message was sent by Atlassian Jira (v8.3.4#803005) --------------------------------------------------------------------- To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org For additional commands, e-mail: issues-h...@lucene.apache.org