[jira] [Resolved] (SOLR-9639) CdcrVersionReplicationTest failure

["Mikhail Khludnev (JIRA)" <ji...@apache.org>]

     [ 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-unsubscribe@lucene.apache.org
For additional commands, e-mail: dev-help@lucene.apache.org