Solr 10.0.0 SolrCloud: Collection creation failure after uptime (SolrServerException: Header size > 8192)

["Koenig, Christian via users" <us...@solr.apache.org>]

Hi everyone,

We recently upgraded a single-node SolrCloud cluster from Solr 9 to Solr 10 and have run into a persistent issue during collection creation. Following the Solr community guidelines, I wanted to discuss this here to see if it's a known regression or an integration bug.

  *
Solr Version: 10.0.0 6c6c48a6f78486130682ea9c1f7a2723af5a87be - anshum - 2026-02-12 16:07:59
  *
Lucene Version: 10.3.2 dadfd90b4401947f4d0387669dc94999fbb2c830 - 2025-11-13 10:41:29
  *
Topology: SolrCloud (Single-node topology running in Docker)
  *
Scale: ~8,000 Cores / ~60,000,000 Total Documents

Immediately following a fresh container restart, creating collections or uploading configsets works perfectly. However, after the node has been up for a multiple days and subjected to some administrative activity, attempting to create a new collection continuously fails with the following exception (see attached logs):

org.apache.solr.client.solrj.SolrServerException: Header size 8945 > 8192

Once the node hits this failure state, all subsequent collection creation requests fail immediately. A full restart of the Solr container temporarily resolves the issue, but it eventually breaks again once the node accumulates some uptime.
The logs indicate that the problem originates from internal inter-node (loopback) communication triggered by the initial collection creation request.

We enabled DEBUG logging for the http2 HpackEncoder (`org.eclipse.jetty.http2.hpack.HpackEncoder`) to trace the payload.
An initial automated log analysis suggested the following hypothesis regarding HTTP/2 header encoding and internal PKI auth tokens, though we haven't been able to verify it independently.
The logs indicate that the issue stems from the internal `SolrAuthV2` cryptographic header ballooning past Jetty's default 8,192-byte limit.

Interestingly, the Jetty HPACK encoder log frames show that it is selecting a literal compression mechanism without dynamically tracking the key-value pairs in the connection table (`LitHuffNHuffVIdx`):

DEBUG (httpShardExecutor-7-thread-1) [] o.e.j.h.h.HpackEncoder encode LitHuffNHuffVIdx:'SolrAuthV2: 172.18.0.2:8983_solr $ 1789981145354 pNNejjOG5lmt...==' to '3fE11f83418b0b...'

Because the token isn't being indexed by the HTTP/2 connection dynamic table over the shard routing loops, the full, large raw string is being re-serialized on inter-node requests. As the PKI context
naturally compounds over time, the payload structurally grows past 8KB (hitting 8,945 bytes in the logs) and triggers a hard rejection from Jetty.
To work around this issue we attempted to increase Jetty's header buffer size via parameters at startup:


  *
-Dsolr.jetty.request.header.size=65535
  *
-Dsolr.jetty.response.header.size=65535

However, these parameters had no effect, the same error citing the 8,192-byte limit reappeared after a few days. We are currently testing whether setting these limits directly inside /opt/solr-10.0.0/server/etc/jetty.xml has the desiered effect.
Has anyone else encountered this behavior in Solr 10?

Thanks in advance for your insights!

Best regards,
Christian