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

Lucene/Solr QA commented on SOLR-13393:
---------------------------------------

| (x) *{color:red}-1 overall{color}* |
\\
\\
|| Vote || Subsystem || Runtime || Comment ||
| {color:red}-1{color} | {color:red} patch {color} | {color:red}  0m  6s{color} 
| {color:red} SOLR-13393 does not apply to master. Rebase required? Wrong 
Branch? See 
https://wiki.apache.org/solr/HowToContribute#Creating_the_patch_file for help. 
{color} |
\\
\\
|| Subsystem || Report/Notes ||
| JIRA Issue | SOLR-13393 |
| JIRA Patch URL | 
https://issues.apache.org/jira/secure/attachment/12965538/SOLR-13393.patch |
| Console output | 
https://builds.apache.org/job/PreCommit-SOLR-Build/370/console |
| Powered by | Apache Yetus 0.7.0   http://yetus.apache.org |


This message was automatically generated.



> ZkClientClusterStateProvider can leak ZkStateReader (and associated watcher 
> threads) if background threads attempt to use it after close() .
> --------------------------------------------------------------------------------------------------------------------------------------------
>
>                 Key: SOLR-13393
>                 URL: https://issues.apache.org/jira/browse/SOLR-13393
>             Project: Solr
>          Issue Type: Bug
>      Security Level: Public(Default Security Level. Issues are Public) 
>            Reporter: Hoss Man
>            Assignee: Hoss Man
>            Priority: Major
>         Attachments: SOLR-13393.patch, SOLR-13393.patch
>
>
> while digging into some test failures related to leaked ZkStateReader 
> objects, i noticed a pattern which i beleive can be explained by the fact 
> that ZkClientClusterStateProvider does not complain/fail if some caller tries 
> to connect()/use it after it's already been closed – in this situation it 
> will just re-create a new ZkStateReader (which is later leaked)
> So in in situations where background/timer threads use a 
> SolrClientCloudManager/ZkClientClusterStateProvider, we might see...
> {noformat}
> T1 : start shutdown...
> T1 :  ...SolrClientCloudManager.close()...
> T1 :   ...ZkClientClusterStateProvider.close()...
> T1 :    ...ZkStateReader.close()
> T1 :    ...zkStateReader = null;
> T 2: run background thread/task/trigger...
> T 2:  ...get ZkClientClusterStateProvider
> T 2:  ...call ZkClientClusterStateProvider.connect()
> T 2:   ...zkStateReader = new ZkStateReader()                 /* LEAKED */
> T 2:  ... do something with ZkClientClusterStateProvider
> T 2:  ...finish background thread/task/trigger
> T1 :  ...finish shutdown of ZkClientClusterStateProvider / 
> SolrClientCloudManager
> {noformat}



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org

Reply via email to