Yes, this is worrisome, it would be great if you could verify this against 10x. I remember fighting similar leaks when adding the Dropwizard gauges.
Andrzej > On 12 Sep 2026, at 01:47, Mikhail Khludnev <[email protected]> wrote: > > Hi, > I've noticed a really odd thing in main branch > https://issues.apache.org/jira/browse/SOLR-18442 > haven't checked it on 10_x > > On Fri, Sep 11, 2026 at 8:46 PM Eric Pugh <[email protected]> > wrote: > >> AB, I’ve deleted the duplicate JIRA’s (first time I’ve ever done that) and >> I’m looking at SOLR-18407 with Matthew Biscocho. We have a candidate PR >> for it. >> >> As far as SOLR-16560, it was opened in 2022 against 8.8, and then was >> updated in October 2025 to 10.0…. Which makes me feel like it’s not >> Critical level…. >> >> >> >> >> >> >>> On Sep 10, 2026, at 8:17 AM, 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] >>>> >>> >>> >>> --------------------------------------------------------------------- >>> 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. >> > > > -- > Sincerely yours > Mikhail Khludnev --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
