br0nstein opened a new issue, #14731:
URL: https://github.com/apache/lucene/issues/14731

   ### Description
   
   updateDocument handled a tragic event but the VirtualMachineError was 
swallowed due to the IndexWriter rollback operation called from the finally 
block itself throwing an exception; therefore we cannot root-cause the origin 
of the issue
   
   > Caused by: java.nio.channels.ClosedChannelException: null
   >    at java.base/sun.nio.ch.FileLockImpl.release(FileLockImpl.java:58)
   >    at java.base/java.nio.channels.FileLock.close(FileLock.java:336)
   >    at 
org.apache.lucene.store.NativeFSLockFactory$NativeFSLock.close(NativeFSLockFactory.java:206)
   >    at org.apache.lucene.util.IOUtils.close(IOUtils.java:88)
   >    at org.apache.lucene.util.IOUtils.close(IOUtils.java:76)
   >    at 
org.apache.lucene.index.IndexWriter.rollbackInternalNoCommit(IndexWriter.java:2357)
   >    at 
org.apache.lucene.index.IndexWriter.rollbackInternal(IndexWriter.java:2288)
   >    at 
org.apache.lucene.index.IndexWriter.maybeCloseOnTragicEvent(IndexWriter.java:4930)
   >    at 
org.apache.lucene.index.IndexWriter.updateDocument(IndexWriter.java:1632)
   >    at 
org.apache.lucene.index.IndexWriter.updateDocument(IndexWriter.java:1608)
   >    at 
com.dremio.datastore.indexed.LuceneSearchIndex.update(LuceneSearchIndex.java:360)
   >    ... 30 common frames omitted
   
   We are using Lucene 7.7.3
   
   In Java it is generally considered an anti-pattern to throw an exception 
from a finally clause as any exception thrown in earlier try/catch clauses are 
hidden. If the finally clause may produce an exception that must be propagated 
somehow, I think it is best to attach that exception as a suppressed exception 
so it can still be logged by callers (or vice versa).
   
   As a side note, is this a bug that rollBackInternalNoCommit tries to close 
the FileLock after the channel has been closed?
   
   Note, we do not enable the InfoStream logger for IndexWriter ("IW"), which 
would have let us see the original error, I believe because it may be noisy 
given these fatal errors and detailed logs for normal operations are both 
logged as messages with no concept of a log level. Other libraries we use tend 
to support slf4j for logging.
   
   ### Version and environment details
   
   _No response_


-- 
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.

To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org.apache.org

For queries about this service, please contact Infrastructure at:
us...@infra.apache.org


---------------------------------------------------------------------
To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org
For additional commands, e-mail: issues-h...@lucene.apache.org

Reply via email to