Hi,

We’ve made very good progress during this week!

The current situation is as follows:

Blockers:

* SOLR-18407: Solr 10 emits duplicate JVM metrics from both 
runtime-telemetry-java8 and runtime-telemetry-java17 scopes on Java 17 
(promoted from Critical to Blocker)
  In progress, does this PR need anything more? 
https://github.com/apache/solr/pull/4907

Critical:

* SOLR-18273: Solr 10.0.0 treats short ZooKeeper leader failover as 
session-expiration recovery and removes/re-registers live_nodes
  I’m not sure what to think about this one - does the fix in SOLR-18298 
resolves / mitigates this?

* SOLR-18442: SolrIndexSearcher is retained for the life of the node by 
OpenTelemetry observable gauges (promoted from Major to Critical)
  In progress, with a potential fix in https://github.com/apache/solr/pull/4917

* SOLR-16560: Pull replication appears to consume excessive CPU as it does not 
use Segment Reader pooling
  This is a fairly old ticket that was recently tagged with 10.0 by Anshum, 
without any comments. If no other confirmation is forthcoming I’m inclined to 
demote this to Major.

Keep ‘em coming, guys :)

Andrzej
  

> On 10 Sep 2026, at 14:17, Andrzej Białecki <[email protected]> wrote:
> 
> Hi,
> 
> As of today, there are still many open Bug tickets affecting 10.0, which 
> presumably should be fixed in 10.1 - or at least they should be evaluated and 
> either downgraded or deliberately scheduled for a later release:
> * 23 Major
> * 6 Critical
> * 4 Blocker
> 
> Blockers:
> 
> * SOLR-18298: ZkController.onReconnect Is Triggered Excessively (PR)
> * SOLR-18301: Overseer Election May Not Converge After ZK Disconnect (PR)
> * SOLR-18324: V2 (JAX-RS) requests can throw a cascading NPE / RTimer 
> assertion failure when a `SolrQueryRequest` isn't attached to the request 
> context (PR)
> * SOLR-18278: SOLR JETTY dependency decoupling didn't work properly
> 
> All are currently Unassigned in Jira but three of them have PRs. SOLR-18278 
> needs to be verified because the description is very sparse.
> 
> Critical:
> 
> * SOLR-18407: Solr 10 emits duplicate JVM metrics from both 
> runtime-telemetry-java8 and runtime-telemetry-java17 scopes on Java 17
> * SOLR-18273: Solr 10.0.0 treats short ZooKeeper leader failover as 
> session-expiration recovery and removes/re-registers live_nodes
> * SOLR-18276: Solr 10.0.0 treats short ZooKeeper leader failover as 
> session-expiration recovery and removes/re-registers live_nodes
> * SOLR-18275: Solr 10.0.0 treats short ZooKeeper leader failover as 
> session-expiration recovery and removes/re-registers live_nodes
> * SOLR-18274: Solr 10.0.0 treats short ZooKeeper leader failover as 
> session-expiration recovery and removes/re-registers live_nodes
> * SOLR-16560: Pull replication appears to consume excessive CPU as it does 
> not use Segment Reader pooling
> 
> SOLR-18276, SOLR-18275 and SOLR-18274 are duplicates of SOLR-18273 and can be 
> closed.
> 
> SOLR-18407, 18273, 16560 are all Unassigned, with no PRs.
> 
> 
> Any input on this list would be appreciated. Please also take a look at the 
> Major tickets, perhaps some of them should be re-evaluated for 10.1, either 
> down- or up-graded.
> 
> Andrzej
> 
> 
> 
>> On 8 Sep 2026, at 17:00, Andrzej Białecki <[email protected]> wrote:
>> 
>> Fine with me, there are still several tickets in-flight that IMHO should be 
>> included in 10.1, so it will take another week or two anyway.
>> 
>> Andrzej
>> 
>>> On 8 Sep 2026, at 12:34, Jan Høydahl <[email protected]> wrote:
>>> 
>>> The no overlap releases has been a self imposed limitation to avoid 
>>> confusion, and I guess it is cleaner to have 9.11 changelog in the 10.1 
>>> release. During RCs there may also surface need for bugfixes that will 
>>> trickle from main, and that could then potentially require re-spin of both 
>>> releases.
>>> 
>>> So if we are to keep with tradition we do 9.x first and then 10.x 
>>> immediately after. But technically we could have both in-flight...
>>> 
>>> Jan
>>> 
>>>> 7. sep. 2026 kl. 16:30 skrev David Smiley <[email protected]>:
>>>> 
>>>> I'm not sure what release overlap concerns exist but I thought there was a
>>>> limitation on concurrent releases.  Maybe Jan knows.
>>>> 
>>>> RE 10.1:  There's https://issues.apache.org/jira/browse/SOLR-18130 on 10.x
>>>> (not 10.0), which opened up a security concern.  It's not released, so no
>>>> reason for me to be too secretative.  I've had the concern on my mental
>>>> backlog for months with code done for it for months likewise but
>>>> frustratingly it's somewhat blocked by other WIP for a vulnerability that I
>>>> don't want to interfere with (i.e. don't want to make backporting harder).
>>>> 
>>>> On Thu, Sep 3, 2026 at 5:03 AM Andrzej Białecki <[email protected]> wrote:
>>>> 
>>>>> Hi all,
>>>>> 
>>>>> A lot of good work already went into branch_10x - dependency updates and
>>>>> important bug fixes. There are also some outstanding bugs that I know 
>>>>> about
>>>>> (SOLR-18414, SOLR-18408 and related CrossDC bugs) that either cripple or
>>>>> completely break certain use cases in 10.0.0.
>>>>> 
>>>>> Solr 10.0.0 has been released exactly 6 months ago. I think it’s time for
>>>>> 10.1. If the community thinks so too, I volunteer to be the release
>>>>> manager. Also, please let me know of any issues that may hold up this
>>>>> release.
>>>>> 
>>>>> Andrzej
>>>>> ---------------------------------------------------------------------
>>>>> To unsubscribe, e-mail: [email protected]
>>>>> For additional commands, e-mail: [email protected]
>>>>> 
>>>>> 
>>> 
>>> 
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: [email protected]
>>> For additional commands, e-mail: [email protected]
>>> 
>> 
>> 
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: [email protected]
>> For additional commands, e-mail: [email protected]
>> 
> 


---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]

Reply via email to