I enhanced https://github.com/apache/solr/pull/3357 to incorporate that test and make other changes. Keeping the IllegalStateException but at least the idle timeout can be set at the request level. The downside is that a number of places in Solr that were customizing the connection timeout can no longer do so. I think it's fine; it strikes me as rather obscure to really _need_ to mess with the connection timeout on a use-case basis. I filed https://issues.apache.org/jira/browse/SOLR-17776 to capture this work.
I'd like to get that into 9.x. On Sat, May 24, 2025 at 8:55 PM Luke Kot-Zaniewski (BLOOMBERG/ 919 3RD A) < lkotzanie...@bloomberg.net> wrote: > That's a good point. I didn't immediately realize it would effectively be > the minimum of the two idle timeout values but now that I think about it, > it makes sense. > > Looking at it from a higher level though, since Jetty appears to honor > idleTimeout at the request level (either through the aforementioned > listener or through client Request itself > https://javadoc.jetty.org/jetty-11/org/eclipse/jetty/client/api/Request.html#idleTimeout(long,java.util.concurrent.TimeUnit) > and considering that we already have a client wrapper that saves these > timeouts, it would make sense to have some convention/validation where we > only set timeouts at the solr client level and actually never proagate it > to the underlying HttpClient (and rather keep those at the max value). This > would make more flexible and allow sharing underlying HttpClients in some > circumstances. Admittedly this might only work for settings that appear to > have jetty request-level overrides, i.e. idle timeouts and request timeouts > (not sure about connectionTimeouts for instance), but maybe that's > something worth exploring? In a project the size of Solr sharing > clients/connections wherever possible might be worthwhile if it can be done > reasonably... > > Sent from Bloomberg Professional for Android > > ----- Original Message ----- > From: David Smiley <dev@solr.apache.org> > To: dev@solr.apache.org > CC: LUKE KOT-ZANIEWSKI, stilla...@apache.org, gus.h...@gmail.com > At: 05/24/25 15:12:28 UTC-04:00 > > > Luke, thanks for writing this test!! > > I looked at your test > (esp. > org.apache.solr.client.solrj.impl.Http2SolrClientTest#testIdleTimeoutWithHttpClient > ) in more detail. You tested going from having a sufficient amount of idle > timeout for the request to succeed, then down to a lower amount, asserting > it failed. But we want the other way around -- low to high. I pushed this > change to your PR and the test failed. Can you look please? Unless I'm > missing something, this failure demonstrates the problem I am ringing the > alarm bells about. > > https://issues.apache.org/jira/browse/SOLR-13605 > Ah, thanks for reminding me. That issue is about Apache based HTTP > SolrClient, and yes, it seems like the "reverse" problem. > > On Thu, May 22, 2025 at 7:47 PM Chris Hostetter <hossman_luc...@fucit.org> > wrote: > > > > > > > : 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). > > > > Deja Vu... > > > > https://issues.apache.org/jira/browse/SOLR-13605 > > > > ...except now we have the reverse problem? > > > > > > > > -Hoss > > http://www.lucidworks.com/ > > > > --------------------------------------------------------------------- > > To unsubscribe, e-mail: dev-unsubscr...@solr.apache.org > > For additional commands, e-mail: dev-h...@solr.apache.org > > > > >
