[jira] [Commented] (SOLR-9639) CdcrVersionReplicationTest failure
[
https://issues.apache.org/jira/browse/SOLR-9639?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15575105#comment-15575105
]
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: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
[jira] [Commented] (SOLR-9639) CdcrVersionReplicationTest failure
[
https://issues.apache.org/jira/browse/SOLR-9639?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15575084#comment-15575084
]
ASF subversion and git services commented on SOLR-9639:
---
Commit 47446733884e030feaecac355c01c58f9e5e3169 in lucene-solr's branch
refs/heads/master from [~mkhludnev]
[ https://git-wip-us.apache.org/repos/asf?p=lucene-solr.git;h=4744673 ]
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: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
[jira] [Commented] (SOLR-9639) CdcrVersionReplicationTest failure
[
https://issues.apache.org/jira/browse/SOLR-9639?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15573038#comment-15573038
]
Alan Woodward commented on SOLR-9639:
-
+1 to the quick fix, let's open a separate JIRA for the cancellation.
> 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: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
[jira] [Commented] (SOLR-9639) CdcrVersionReplicationTest failure
[
https://issues.apache.org/jira/browse/SOLR-9639?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15572892#comment-15572892
]
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: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
[jira] [Commented] (SOLR-9639) CdcrVersionReplicationTest failure
[
https://issues.apache.org/jira/browse/SOLR-9639?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15572767#comment-15572767
]
Alan Woodward commented on SOLR-9639:
-
I think we need a way to cancel or interrupt PeerSync from RecoveryStrategy?
> 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: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
