[ https://issues.apache.org/jira/browse/SOLR-9639?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Mikhail Khludnev resolved SOLR-9639. ------------------------------------ Resolution: Fixed follow up SOLR-9645 > CdcrVersionReplicationTest failure > ---------------------------------- > > Key: SOLR-9639 > URL: https://issues.apache.org/jira/browse/SOLR-9639 > Project: Solr > Issue Type: Bug > Security Level: Public(Default Security Level. Issues are Public) > Reporter: Mikhail Khludnev > Fix For: 6.3, master (7.0) > > Attachments: CDcr failure.txt, SOLR-9639.patch, SOLR-9639.patch, > cdcr-stack.txt, cdcr-success.txt > > > h3. it fails. > The problem is [over > there|https://github.com/apache/lucene-solr/blob/master/solr/core/src/test/org/apache/solr/cloud/BaseCdcrDistributedZkTest.java#L597] > when it deletes that temporal collection (which is a tricky thing per se) > while it's still in recovery Solr Cloud went crazy: it closes the core, and > almost done it, but it can't be unloaded because PeerSync (remember, it's > recovering) open it ones, and it bloat logs with > bq.105902 INFO (qtp3284815-656) [n:127.0.0.1:41440_ia%2Fd ] > o.a.s.c.SolrCore Core collection1 is not yet closed, waiting 100 ms before > checking again. > But then, something spawn too many request {{/get}}?? which deadlocks until > heap is exceeded and it dies. The fix is obvious, just to wait until > recoveries finishes, before removing tmp_collection. > Beside of this particular fix,is there any ideas about deadlock caused by > deleting recovering collection? -- This message was sent by Atlassian JIRA (v6.3.4#6332) --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org