[
https://issues.apache.org/jira/browse/SOLR-12232?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16441890#comment-16441890
]
Jeff Miller commented on SOLR-12232:
------------------------------------
The thread interrupting is purposeful for our solution and won't be changing
anytime soon due to external requirements. It worked just fine for quite a few
years until the call to ensureValid was added. Since I saw no specific
requirement for this class to close its file channel due to an interrupt
exception it seemed a decent solution incase anyone else out there uses
interrupts in any manner without removing the ensureValid call for us. If no
one sees value in this for Solr then so be it.
> NativeFSLockFactory loses the channel when a thread is interrupted and the
> SolrCore becomes unusable after
> ----------------------------------------------------------------------------------------------------------
>
> Key: SOLR-12232
> URL: https://issues.apache.org/jira/browse/SOLR-12232
> Project: Solr
> Issue Type: Bug
> Security Level: Public(Default Security Level. Issues are Public)
> Affects Versions: 7.1.1
> Reporter: Jeff Miller
> Assignee: Erick Erickson
> Priority: Minor
> Labels: NativeFSLockFactory, locking
> Original Estimate: 24h
> Time Spent: 10m
> Remaining Estimate: 23h 50m
>
> The condition is rare for us and seems basically a race. If a thread that is
> running just happens to have the FileChannel open for NativeFSLockFactory and
> is interrupted, the channel is closed since it extends
> [AbstractInterruptibleChannel|https://docs.oracle.com/javase/7/docs/api/java/nio/channels/spi/AbstractInterruptibleChannel.html]
> Unfortunately this means the Solr Core has to be unloaded and reopened to
> make the core usable again as the ensureValid check forever throws an
> exception after.
> org.apache.lucene.store.AlreadyClosedException: FileLock invalidated by an
> external force:
> NativeFSLock(path=data/index/write.lock,impl=sun.nio.ch.FileLockImpl[0:9223372036854775807
> exclusive invalid],creationTime=2018-04-06T21:45:11Z) at
> org.apache.lucene.store.NativeFSLockFactory$NativeFSLock.ensureValid(NativeFSLockFactory.java:178)
> at
> org.apache.lucene.store.LockValidatingDirectoryWrapper.createOutput(LockValidatingDirectoryWrapper.java:43)
> at
> org.apache.lucene.store.TrackingDirectoryWrapper.createOutput(TrackingDirectoryWrapper.java:43)
> at
> org.apache.lucene.codecs.compressing.CompressingStoredFieldsWriter.<init>(CompressingStoredFieldsWriter.java:113)
> at
> org.apache.lucene.codecs.compressing.CompressingStoredFieldsFormat.fieldsWriter(CompressingStoredFieldsFormat.java:128)
> at
> org.apache.lucene.codecs.lucene50.Lucene50StoredFieldsFormat.fieldsWriter(Lucene50StoredFieldsFormat.java:183)
>
> Proposed solution is using AsynchronousFileChannel instead, since this is
> only operating on a lock and .size method
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
