Matthew and I have gone back and forth on SOLR-18407 / PR 4907 and I think it’s on the verge of being mergable, so Friday would make sense for that. I don’t think I can weigh in on the two critical bugs ;-(
> On Sep 22, 2026, at 2:02 AM, Andrzej Białecki <[email protected]> wrote: > > Hi, > > Current status of tickets scheduled for 10.1: > > Blockers: > > * SOLR-18407: Solr 10 emits duplicate JVM metrics from both > runtime-telemetry-java8 and runtime-telemetry-java17 scopes on Java 17 > In progress https://github.com/apache/solr/pull/4907 > <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 > Same question as before: does the fix in SOLR-18298 resolves / mitigates > this? @epugh, @mlbiscoc, @hossman - could you please take a look at this? > > * SOLR-16560: Pull replication appears to consume excessive CPU as it does > not use Segment Reader pooling > There was no further input since the last report - since it’s unconfirmed at > this point I’m demoting it to Major. > > If we can close the single remaining Blocker and decide the fate of the > Critical tickets in some way (close, demote, fix) I propose to create > branch_10_1 by Friday Sep 25, end of day (UTC). > > Andrzej > > > > On 17 Sep 2026, at 12:15, Andrzej Białecki <[email protected]> wrote: > > > > 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 > > <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 > > <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 > >>>>> <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] > >>> > >> > > > Disclaimer The information contained in this communication from the sender is confidential. It is intended solely for use by the recipient and others authorized to receive it. If you are not the recipient, you are hereby notified that any disclosure, copying, distribution or taking action in relation of the contents of this information is strictly prohibited and may be unlawful. This email has been scanned for viruses and malware, and may have been automatically archived by Mimecast, a leader in email security and cyber resilience. Mimecast integrates email defenses with brand protection, security awareness training, web security, compliance and other essential capabilities. Mimecast helps protect large and small organizations from malicious activity, human error and technology failure; and to lead the movement toward building a more resilient world. To find out more, visit our website.
