[
https://issues.apache.org/jira/browse/SOLR-11297?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16151045#comment-16151045
]
Erick Erickson commented on SOLR-11297:
---------------------------------------
I poked around a little more and
https://issues.apache.org/jira/browse/LUCENE-6525 started the deprecation
process for writeLockTimeout. Most of the 7x references to it were removed in
master, but there's still a single reference even in Master. I've pinged the
dev list about whether we should remove them all.
But the net-net is that changing that in any 7x version and even 6x doesn't
reference it (didn't check early 6 versions, just current 6x). I was looking at
5x code when I saw it had an effect.
So it's no surprise that it didn't have any effect for you [~elyograg].
Anyway, that was just to see if you were seeing something I was looking at in
5x to see how pervasive this was as I was starting to dig as to why it is
happening. The JIRA talks about using SleepingLockWrapper, but that's not
exposed in Solr at this point and I don't see any point in exposing it for this
problem since it's a band-aid not a proper fix.
Sorry for the misdirection
Erick
> Message "Lock held by this virtual machine" during startup. Solr is trying
> to start some cores twice
> -----------------------------------------------------------------------------------------------------
>
> Key: SOLR-11297
> URL: https://issues.apache.org/jira/browse/SOLR-11297
> Project: Solr
> Issue Type: Bug
> Security Level: Public(Default Security Level. Issues are Public)
> Affects Versions: 6.6
> Reporter: Shawn Heisey
> Assignee: Erick Erickson
> Attachments: solr6_6-startup.log
>
>
> Sometimes when Solr is restarted, I get some "lock held by this virtual
> machine" messages in the log, and the admin UI has messages about a failure
> to open a new searcher. It doesn't happen on all cores, and the list of
> cores that have the problem changes on subsequent restarts. The cores that
> exhibit the problems are working just fine -- the first core load is
> successful, the failure to open a new searcher is on a second core load
> attempt, which fails.
> None of the cores in the system are sharing an instanceDir or dataDir. This
> has been verified several times.
> The index is sharded manually, and the servers are not running in cloud mode.
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
