Nice find. Look forward to seeing the PR as the IndexFetcher timeout regression 
has already bitten us. I guess my attempt to fix it 
(https://github.com/apache/solr/pull/3356) is doomed to fail as it currently 
stands?

From: dev@solr.apache.org At: 05/19/25 09:46:11 UTC-4:00To:  dev@solr.apache.org
Cc:  Luke Kot-Zaniewski (BLOOMBERG/ 919 3RD A ) ,  stilla...@apache.org,  
gus.h...@gmail.com
Subject: SolrJ timeouts

This weekend I was harmonizing some of the timeouts between JDK & Jetty
based HTTP SolrClient implementations.  I saw some inconsistencies,
duplication, and the need for javadocs to explain what these timeouts
fundamentally mean.  I have some nice WIP code I was looking forward to
sharing by now.

Then I noticed something insidious:  If an Http2SolrClient (Jetty) is
created using the builder's withHttpClient(...) method, then the idle (aka
socket) timeout & connection timeout (and basically any other setting
that's inside the Jetty HttpClient) cannot *actually* be customized
henceforth.  This should be pretty obvious, when you think about it (duh).
But we don't do any checks in construction to alert you, plus we
redundantly put some of these settings on the Http2SolrClient (incl. base
class) which fools any onlooker into thinking it might do something.  My
WIP addresses this by throwing an IllegalArgumentException on build() if
you try to set something that won't take effect.  This revealed a number of
prominent places in Solr that both call withHttpClient and also customize
the timeouts (to no avail):  Overseer, SolrClientCache (for streaming
expressions), IndexFetcher, and some recovery stuff; maybe I missed
something.  This solution won't work.

Perhaps withHttpClient should not reuse the underlying HttpClient?  It's a
shame to not reuse it but it's at least the safest choice.  In my opinion,
withHttpClient doesn't have an ideal name either; it should be
withHttpSolrClient.  Its current name is ambiguous; I hate confusing
HttpSolrClient with HttpClient.  And if we copy configuration from the
client but don't actually use it, then maybe we should name this method
copyConfigurationFrom or withConfigurationFrom.

I'll throw up a draft PR today that does the cleanup/harmonization but not
yet solve the above conundrum.

(CC'ed some folks that worked on timeouts)

~ David Smiley
Apache Lucene/Solr Search Developer
http://www.linkedin.com/in/davidwsmiley


Reply via email to