[ 
https://issues.apache.org/jira/browse/SOLR-10420?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15970030#comment-15970030
 ] 

Scott Blum commented on SOLR-10420:
-----------------------------------

Let me try to unpack what you said..

1) We want a synchronous offer() -> peek() on the same thread to return the 
item offered without delay.
2) This works on master, but the original patch to fix the leak breaks #1.

Is that correct?

Let me look at this on Monday with [~jhump].  I'm pretty sure there's a 
simplification to be made in DQ with how we're handling the watcher and dirty 
tracking.  There used to be an explicit "isDirty" bit that we traded out for 
watcher nullability, which in retrospect I'm not sure was the best choice.

> 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
>         Attachments: OverseerTest.106.stdout, OverseerTest.119.stdout, 
> OverseerTest.80.stdout, OverseerTest.DEBUG.43.stdout, 
> OverseerTest.DEBUG.48.stdout, OverseerTest.DEBUG.58.stdout, 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

Reply via email to