[
https://issues.apache.org/jira/browse/SOLR-7836?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14698752#comment-14698752
]
Erick Erickson commented on SOLR-7836:
--------------------------------------
[~markrmil...@gmail.com] If you check out trunk revision 1694809, then the
stack trace above in the deadlock_5_pass_iw.res.zip is the problem I hit by
passing the indexwriter down to DUH2.addanddelete. It really doesn't help
because updatelog.add has this bit of code:
try {
RefCounted e1 = this.uhandler.core.openNewSearcher(true, true);
e1.decref();
} catch (Exception var8) {
SolrException.log(log, "Error opening realtime searcher for
deleteByQuery", var8);
}
so the IW passed to addAndDelete in DUH2 doesn't make a difference, the fact
that the IW is held open is blocking the call to openNewSearcher above; it
doesn't matter whether addAndDelete has an already opened IW passed in or opens
its own, as long as the IW is open across the call to ulog.add(), a deadlock
occurs. Sometimes.
Based on the exception message, would a better approach be to open up the new
searcher in delete by query instead? Would that cover all the cases? I'll look
a little here. Then I could move all the ulog.add()s back inside the associated
IW and again tightly couple the document adds with updating the ulog.
Or maybe the answer is making realtime searchers sensitive to whether
anything's been indexed since the last time it was opened rather than
pre-opening a new one in addDoc0(). Don't even know if it's possible, haven't
looked yet. Essentially this would make opening a realtime searcher "lazy".
Which I can argue is a better solution than adding this overhead to all
updates, although it also seems it would make realtime gets vary a lot
depending on whether they had to open a searcher or not.
> Possible deadlock when closing refcounted index writers.
> --------------------------------------------------------
>
> Key: SOLR-7836
> URL: https://issues.apache.org/jira/browse/SOLR-7836
> Project: Solr
> Issue Type: Bug
> Reporter: Erick Erickson
> Assignee: Erick Erickson
> Fix For: Trunk, 5.4
>
> Attachments: SOLR-7836-synch.patch, SOLR-7836.patch, SOLR-7836.patch,
> SOLR-7836.patch, deadlock_3.res.zip, deadlock_5_pass_iw.res.zip, deadlock_test
>
>
> Preliminary patch for what looks like a possible race condition between
> writerFree and pauseWriter in DefaultSorlCoreState.
> Looking for comments and/or why I'm completely missing the boat.
--
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
