[
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
