Investigate Failing Test: Lucene.Net.Index.TestIndexWriterOnJRECrash::TestNRTThreads_Mem()

[NightOwl888]

Is there an existing issue for this?

• I have searched the existing issues

Task description

This test was ported and added in #786 (to close #768).

Unfortunately, it fails intermittently. A user shared in Lucene.net corrupted index (segments.gen) on StackOverflow that this appears to be due to a real problem that happens in production.

The failure may or may not be related to the deprecation of thread interrupts (#555) in Lucene.NET which were supported in the Java version. We make a best effort to support them using UninterrruptableMonitor instead of lock statements, but since a lock may be taken in any library we depend on that may throw ThreadInterruptedException from the action of taking a lock, we cannot 100% guarantee that we can catch every one of these exceptions in order to rollback an in-process commit. In Java, taking a lock does not throw an exception in any case.

[NightOwl888]

I am raising priority on this and adding it as a production blocker because we are missing durability (ACID). A commit done simultaneously with a power outage will result in a corrupt index about 1 time out of 200. This only occurs on .NET Core, not on .NET Framework.

We looked at this a bit already. Now that we have completed fsync support, we expected this to automatically work. Since it doesn't fail on .NET Framework, it seems probable there is something going on at a very deep level inside of .NET Core where the behavior has changed.