Hi Dario, I was able to reproduce the issue using your test-class.
Doing some digging, I think the issue is caused by how the default executor is configured, corePoolSize=4, and the fact that the executor pool is used for two different things, for the HttpClient and for ContentWriter. In the thread-dump, I can see ContentWriter holding all 4 threads, so no threads from the pool left for the HttpClient. That explains why it works fine with 3 concurrent queries. For smaller queries that might not be an issue, since ContentWriter writes it in one go, and does not have to wait for the HttpClient to consume the data. I will open a Jira, I think separating the two thread pools might the way to fix it. Cheers, Renato > On 21 Jul 2026, at 17:03, <[email protected]> <[email protected]> wrote: > > Hi Solr team, > > I've discovered a reproducible bug in the HttpJdkSolrClient where the client > becomes permanently blocked after sending concurrent requests with > sufficiently long queries. > Behaviour > When sending 4 or more parallel requests with very long queries the client's > internal task queue fills up completely and the client stops communicating > with Solr entirely. > > Conditions to reproduce > > > * > 4+ parallel requests sent simultaneously > * > Query length with more than ~900 characters > * > Using HttpJdkSolrClient > > Additional observations > > * Sending more than 4 parallel requests within the safe character limit > does not permanently block the client - some requests throw exceptions, but > the client recovers. > * Sending 3 parallel requests with queries well above the threshold also > does not permanently block the client. > * The Solr server version does not appear to affect this behaviour. > > Additional observations > > * Sending more than 4 parallel requests within the safe character limit > does not permanently block the client - some requests throw exceptions, but > the client recovers. > * Sending 3 parallel requests with queries well above the threshold also > does not permanently block the client. > * The Solr server version does not appear to affect this behaviour. > > Workaround > Providing a custom ExecutorService resolves the issue. The specific executor > seems almost irrelevant. > > new HttpJdkSolrClient.Builder(DEFAULT_SOLR_URL) > .withConnectionTimeout(CONNECTION_TIMEOUT_MS, TimeUnit.MILLISECONDS) > .withRequestTimeout(REQUEST_TIMEOUT_MS, TimeUnit.MILLISECONDS) > .withExecutor(Executors.newVirtualThreadPerTaskExecutor()) > .useHttp1_1(true) > .build() > > Demo repository > https://github.com/DarioViva42/solr-blocking-demo/tree/main > > Happy to provide additional information or testing. > > Best regards, > > Dario Viva >
