[
https://issues.apache.org/jira/browse/SOLR-9278?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15533661#comment-15533661
]
Michael Braun commented on SOLR-9278:
-------------------------------------
We are running this patch on top of 6.2.1 on our cluster and have not run into
the issue in [SOLR-9470] again. Is someone able to take a look at it to see if
it can fit into the regular release?
> Possible deadlock in replication
> --------------------------------
>
> Key: SOLR-9278
> URL: https://issues.apache.org/jira/browse/SOLR-9278
> Project: Solr
> Issue Type: Bug
> Security Level: Public(Default Security Level. Issues are Public)
> Components: Server
> Affects Versions: 6.1
> Environment: Linux
> Reporter: Xunlong
> Labels: replication
> Fix For: master (7.0)
>
> Attachments: SOLR-9278.patch
>
> Original Estimate: 48h
> Remaining Estimate: 48h
>
> There is a bug in IndexFetcher for replication logic, it may cause deadlock
> issue, and it's very easy to reproduce. If you change your solrconfig to keep
> more than 1 commit points, this operation will causes 2 issues:
> 1. Slave has to download whole index directory of Master, instead of
> incremental udpates only;
> 2. If you click "replicate now" button manually, this is cause deadlock, stop
> both "indexFetcher" thread and "explicitFetcher" thread.
> The first issue is a design issue, can be worked around by keep only 1 commit
> point. But the second issue can always happen if there is some file located
> in slave's index directory, but can not be deleted by index delete policy
> (due to permission issue etc), I have fixed this issue for my service, would
> happy to contribute to Solr community to benefit others.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
