[
https://issues.apache.org/jira/browse/SOLR-7836?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14679424#comment-14679424
]
Mark Miller commented on SOLR-7836:
-----------------------------------
What about the nightly test?
{noformat}
//new code
synchronized (solrCoreState.getUpdateLock()) {
if (ulog != null) ulog.add(cmd);
}
{noformat}
While that says getUpdateLock, it appears to have been additionally proposed as
a deleteLock judging by it's callers and variable name. It looks like the old
index update lock was tied into also being a delete lock.
What is the logic that says you now need that also locking adds other than this
test? Why would the index update lock that did not block adds and also was used
as a delete lock also lock adds now?
[~ysee...@gmail.com] should really look at this as this looks like his code
area.
I'm skeptical that this is the right fix.
> 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
>
>
> 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
