[
https://issues.apache.org/jira/browse/SOLR-11297?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16151045#comment-16151045
]
Erick Erickson edited comment on SOLR-11297 at 9/1/17 7:24 PM:
---------------------------------------------------------------
I poked around a little more and
https://issues.apache.org/jira/browse/LUCENE-6525 started the deprecation
process for writeLockTimeout. Most of the references to it were removed in 7x
and even 6x doesn't use it for all it can be set. In master there's still a
single reference in a test... 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 use
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
was (Author: erickerickson):
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]
