Mikhail Khludnev commented on SOLR-9639:

Don't you want to fix ci first with this one liner, and implement reasonable 
break at recovery then?  

> 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
>         Attachments: CDcr failure.txt, 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:    ] 
> 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

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

Reply via email to