Another thing to think about is that ping would ideally have different authz so that the lb doesnt have read access
http://www.needhamsoftware.com (work) https://a.co/d/b2sZLD9 (my fantasy fiction book) On Fri, Sep 4, 2026, 7:16 AM Eric Pugh <[email protected]> wrote: > Can you elaborate on “register a search handler”…. I think it’s probably > something worth documenting in our Ref Guide. I’ve mostly used the Ping > request handler not just to know solr is there, but also to make sure there > is data in it. > > I was thinking I would maybe look at augmenting what Healthcheck does to > look for data, but if there is already a better way and we just need to > document it? > > > > > On Sep 3, 2026, at 8:48 PM, David Smiley <[email protected]> wrote: > > > > /admin/ping at least communicates _intent_ (purpose) but any way, it's > > trivial to just register a SearchHandler to accomplish exactly that if a > > user wishes. > > > > On Thu, Sep 3, 2026 at 3:41 PM Jason Gerlowski <[email protected]> > > wrote: > > > > > > Right now however, Ping is the only way to validate a core is giving > > > searches. > > > > > > Is it? Couldn't a user just use "/select" for this? > > > > > > > Healthcheck doesn’t do that, > > > > > > It doesn't run an actual query, but you can have it check on the > > > health of cores via its 'requireHealthyCores' param. I get that this > > > isn't quite the same thing as getting a 200 OK on a query, but well, > > > as I said above "/select" can serve for that usecase just fine > > > seemingly? > > > > > > > +1 > > > > > > Awesome - given what seems like consensus here I've created a JIRA > > > ticket (https://issues.apache.org/jira/browse/SOLR-18417 < > https://issues.apache.org/jira/browse/SOLR-18417>) and will > > > make sure this gets done soon! > > > > > > Best, > > > > > > Jason > > > > > > On Sun, Aug 30, 2026 at 9:32 AM Eric Pugh > > > <[email protected]> wrote: > > > > > > > > This would be a nice opportunity to let the existing > HealthcheckHandler > > > shine! It is buried in our ref guide: > > > > https://solr.apache.org/guide/solr/latest/configuration-guide/implicit-requesthandlers.html > < > https://solr.apache.org/guide/solr/latest/configuration-guide/implicit-requesthandlers.html > > > > > and not used in our Solr Admin UI. > > > > > > > > We would need to remove the ping request handler form Solr Admin and > add > > > Healthcheck, but that is an easy change. > > > > > > > > Right now however, Ping is the only way to validate a core is giving > > > searches. Healthcheck doesn’t do that, so if we wanted it to also check > > > that a collection/core was available, then we would need to add that > or we > > > lose capability. > > > > > > > > So +1 on the deprecation, and maybe an opportunity to lay out a nice > > > JIRA with what improvements to HealthcheckHandler are needed? > > > > > > > > > > > > > > > > > > > > > On Aug 30, 2026, at 8:12 AM, David Smiley <[email protected]> > wrote: > > > > > > > > > > +1 > > > > > > > > > > On Sun, Aug 30, 2026 at 7:22 AM Jason Gerlowski < > [email protected] > > > > > > > > > wrote: > > > > > > > > > >> Solr has an API called the "PingRequestHandler" > > > > >> (/solr/<coreName>/admin/ping). This API is meant to serve as a > > > > >> load-balancer healthcheck, but it has a few surprising quirks. > Most > > > > >> significantly it operates at the core level rather than the > > > > >> node-level, so it requires load-balancers be aware of Solr's > topology > > > > >> to some extent (which of course, very few off-the-shelf load > balancers > > > > >> are.) > > > > >> > > > > >> In my experience, PingRequestHandler has long been superseded by > less > > > > >> idiosyncratic alternatives like the HealthcheckHandler or even the > > > > >> SystemInfoHandler. > > > > >> > > > > >> **I propose we deprecate PingRequestHandler in 10.x and remove in > > > > >> 11**, unless there's a compelling use-case that someone can bring > to > > > > >> our attention. Not only is it needless maintenance burden, but > > > > >> PingRequestHandler also has some security baggage (i.e. "qt" > usage) > > > > >> that makes it slightly risky to keep around if it's not providing > > > > >> value. > > > > >> > > > > >> Absent any use-cases for it that I'm not seeing currently, I'll > create > > > > >> a ticket for this in a few days and start working towards > > > > >> deprecation+removal. Let me know what you guys think! Does anyone > > > > >> here use PingRequestHandler in a way that couldn't be replaced by > > > > >> HealthcheckHandler or normal querying? > > > > >> > > > > >> Best, > > > > >> > > > > >> Jason > > > > >> > > > > >> > --------------------------------------------------------------------- > > > > >> To unsubscribe, e-mail: [email protected] > > > > >> For additional commands, e-mail: [email protected] > > > > >> > > > > >> > > > > > > > > Disclaimer > > > > > > > > The information contained in this communication from the sender is > > > confidential. It is intended solely for use by the recipient and others > > > authorized to receive it. If you are not the recipient, you are hereby > > > notified that any disclosure, copying, distribution or taking action in > > > relation of the contents of this information is strictly prohibited > and may > > > be unlawful. > > > > > > > > This email has been scanned for viruses and malware, and may have > been > > > automatically archived by Mimecast, a leader in email security and > cyber > > > resilience. Mimecast integrates email defenses with brand protection, > > > security awareness training, web security, compliance and other > essential > > > capabilities. Mimecast helps protect large and small organizations from > > > malicious activity, human error and technology failure; and to lead the > > > movement toward building a more resilient world. To find out more, > visit > > > our website. > > > > > > --------------------------------------------------------------------- > > > To unsubscribe, e-mail: [email protected] > > > For additional commands, e-mail: [email protected] > > > > > > > > Disclaimer > > The information contained in this communication from the sender is > confidential. It is intended solely for use by the recipient and others > authorized to receive it. If you are not the recipient, you are hereby > notified that any disclosure, copying, distribution or taking action in > relation of the contents of this information is strictly prohibited and may > be unlawful. > > This email has been scanned for viruses and malware, and may have been > automatically archived by Mimecast, a leader in email security and cyber > resilience. Mimecast integrates email defenses with brand protection, > security awareness training, web security, compliance and other essential > capabilities. Mimecast helps protect large and small organizations from > malicious activity, human error and technology failure; and to lead the > movement toward building a more resilient world. To find out more, visit > our website. >
