ASF subversion and git services commented on SOLR-9639:

Commit 96e0c2ff48cf70f9c376760e50b78281699d0e53 in lucene-solr's branch 
refs/heads/branch_6x from [~mkhludnev]
[ https://git-wip-us.apache.org/repos/asf?p=lucene-solr.git;h=96e0c2f ]

SOLR-9639: CDCR Tests only fix. Wait until recovery is over before
remove the tmp_colletion.

> 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, 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