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 > >
