Great find Kevin! That makes sense. Can confirm that starting with
--jvm-opts "-Djava.io.tmpdir=$(cd $TMPDIR; pwd -P)" works too. Also, thanks
for the PR!
I'd say that fixing this by passing "pwd -P" in the start opts in bin/solr
_seems_ like the right way to go. But I am also conflicted on wheth
Its not just a main / Jetty 12 issue. This should be backported to 9.x as
well where security manager isn't going away.
Kevin Risden
On Thu, May 22, 2025 at 11:22 AM Rahul Goswami
wrote:
> Great find Kevin! That makes sense. Can confirm that starting with
> --jvm-opts "-Djava.io.tmpdir=$(cd $
: 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
: hen
Greetings all,
After upgrading some of our Solr clouds to Solr 9.8, we’ve seen increased
recovery times and occasional recovery failures for 9.8 clouds with large
indexes. Several different exceptions are thrown during recovery failures, but
they all seem to have a shared root cause:
Caused by:
For some reason the paragraphs of this post got smashed together after I
submitted it to the list. My apologies!
From: dev@solr.apache.org At: 05/22/25 18:44:38 UTC-4:00To: dev@solr.apache.org
Subject: Jetty HTTP2 causing Solr Direct Buffer Memory OOMs
Greetings all,
After upgrading some of our
Hi David,
I added the test you suggested here https://github.com/apache/solr/pull/3362
Surprisingly they pass. I think it is because although the idleTimeout set on
the jetty HttpClient passed into the Http2SolrClient remains unchanged, the
Http2SolrClient-level timeout is still enforced via Je
