OrchardCore: Lucene: lock obtain timed out

Okay, thanks for the info.

Hmm, looking again at the stack trace, I see twice Lucene.Net.Index.IndexWriter..ctor, so first it would mean that you have 2 search indexes related to the content type of the item that is published, right?

Then, because for a given index we build a writer once, it would mean at least that the tenant was rebuild (for example after updating some admin settings), or that the application was re-started, not necessarily just before the failing publish but since the previous one.

So still possible that a writer was not well disposed, maybe we would need to check the underlying lucene lock more in depth, for example by using IndexWriter.IsLocked(directory). Hmm as I remember I suggested such things in an old PR where I wanted to make it working even if multiple instances was sharing the same file system.

In the meantime for info I let you read the writer dispose summary comments where we see that this may be a costly operation, an use case where the write lock will still be held, how to force the write lock to be released (dangerous) and so on. Also see the last note in case of a OutOfMemoryException.

    /// <summary>
    /// Commits all changes to an index, waits for pending merges
    /// to complete, and closes all associated files.
    /// <para/>
    /// This is a "slow graceful shutdown" which may take a long time
    /// especially if a big merge is pending: If you only want to close
    /// resources use <see cref="Rollback()"/>. If you only want to commit
    /// pending changes and close resources see <see cref="Dispose(bool)"/>.
    /// <para/>
    /// Note that this may be a costly
    /// operation, so, try to re-use a single writer instead of
    /// closing and opening a new one.  See <see cref="Commit()"/> for
    /// caveats about write caching done by some IO devices.
    ///
    /// <para> If an <see cref="Exception"/> is hit during close, eg due to disk
    /// full or some other reason, then both the on-disk index
    /// and the internal state of the <see cref="IndexWriter"/> instance will
    /// be consistent.  However, the close will not be complete
    /// even though part of it (flushing buffered documents)
    /// may have succeeded, so the write lock will still be
    /// held.</para>
    ///
    /// <para> If you can correct the underlying cause (eg free up
    /// some disk space) then you can call <see cref="Dispose()"/> again.
    /// Failing that, if you want to force the write lock to be
    /// released (dangerous, because you may then lose buffered
    /// docs in the <see cref="IndexWriter"/> instance) then you can do
    /// something like this:</para>
    ///
    /// <code>
    /// try 
    /// {
    ///     writer.Dispose();
    /// } 
    /// finally 
    /// {
    ///     if (IndexWriter.IsLocked(directory)) 
    ///     {
    ///         IndexWriter.Unlock(directory);
    ///     }
    /// }
    /// </code>
    /// 
    /// after which, you must be certain not to use the writer
    /// instance anymore.
    ///
    /// <para><b>NOTE</b>: if this method hits an <see cref="OutOfMemoryException"/>
    /// you should immediately dispose the writer, again.  See 
    /// <see cref="IndexWriter"/> for details.</para>
    /// </summary>
    /// <exception cref="IOException"> if there is a low-level IO error </exception>
    [MethodImpl(MethodImplOptions.NoInlining)]
    public void Dispose()