[
https://issues.apache.org/jira/browse/SOLR-10420?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15973330#comment-15973330
]
Steve Rowe commented on SOLR-10420:
-----------------------------------
bq.
I think at a minimum you should also commit to branch_6_5, since it's a known
release, since you'll be better equipped to handle conflicts if there are any.
I noticed you set fixVersion to releases on branches you won't be committing
to: 6.4.3, 5.5.5. I don't think you should do that. If you're going to commit
to branch_5x, then the fixVersion would be 5.6, since that's the next release
on that branch. Unless you commit to branch_6_4, you shouldn't include 6.4.3
as a fixVersion.
More generally, if you think it's essential that any X.Y.Z release includes
this fix, i.e. that it would be a mistake to release without it, then you
should commit to the branch from which that release will be made. Otherwise
you and others may/will forget to backport when such a release materializes.
> Solr 6.x leaking one SolrZkClient instance per second
> -----------------------------------------------------
>
> Key: SOLR-10420
> URL: https://issues.apache.org/jira/browse/SOLR-10420
> Project: Solr
> Issue Type: Bug
> Security Level: Public(Default Security Level. Issues are Public)
> Affects Versions: 5.5.2, 6.4.2, 6.5
> Reporter: Markus Jelsma
> Assignee: Scott Blum
> Fix For: 5.5.5, 6.4.3, 6.5.1, 6.6, master (7.0)
>
> Attachments: OverseerTest.106.stdout, OverseerTest.119.stdout,
> OverseerTest.80.stdout, OverseerTest.DEBUG.43.stdout,
> OverseerTest.DEBUG.48.stdout, OverseerTest.DEBUG.58.stdout,
> SOLR-10420-dragonsinth.patch, SOLR-10420.patch, SOLR-10420.patch,
> SOLR-10420.patch, SOLR-10420.patch, SOLR-10420.patch
>
>
> One of our nodes became berzerk after a restart, Solr went completely nuts!
> So i opened VisualVM to keep an eye on it and spotted a different problem
> that occurs in all our Solr 6.4.2 and 6.5.0 nodes.
> It appears Solr is leaking one SolrZkClient instance per second via
> DistributedQueue$ChildWatcher. That one per second is quite accurate for all
> nodes, there are about the same amount of instances as there are seconds
> since Solr started. I know VisualVM's instance count includes
> objects-to-be-collected, the instance count does not drop after a forced
> garbed collection round.
> It doesn't matter how many cores or collections the nodes carry or how heavy
> traffic is.
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
