[
https://issues.apache.org/jira/browse/LUCENENET-603?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Shad Storhaug resolved LUCENENET-603.
-------------------------------------
Resolution: Fixed
Assignee: Shad Storhaug
Fix Version/s: Lucene.Net 4.8.0
The issue was with the implementation of {{ThreadClass}}. It was allowing
exceptions to be thrown on the background thread instead of catching them and
throwing on the thread that spawned it. It has now been patched in commit
[3ba63c9d737a31204d214916184de109c4507234|https://github.com/apache/lucenenet/commit/3ba63c9d737a31204d214916184de109c4507234]
and is now in release 4.8.0-beta00006.
There was a similar problem with {{TaskMergeScheduler}} in that it didn't throw
the {{MergeException}} at all during a merge failure, which has also been
patched.
> ConcurrentMergeScheduler crashes the application if a transient error occurs
> ----------------------------------------------------------------------------
>
> Key: LUCENENET-603
> URL: https://issues.apache.org/jira/browse/LUCENENET-603
> Project: Lucene.Net
> Issue Type: Improvement
> Components: Lucene.Net Core
> Affects Versions: Lucene.Net 3.0.3, Lucene.Net 4.8.0
> Reporter: Laura Nash
> Assignee: Shad Storhaug
> Priority: Major
> Labels: easyfix, newbie
> Fix For: Lucene.Net 4.8.0
>
>
> We are using Lucene.NET 3.0.3 within a larger application hosted in a Windows
> Service. The Lucene.NET use occurs in a background processing thread and is
> non-critical, it shouldn't ever cause the Windows Service to crash.
> Currently if an error occurs (even a very transient error) within our
> implementation of Lucene.Net.Store.BufferedIndexOutput FlushBuffer() then our
> Windows Service crashes.
> This is because ConcurrentMergeScheduler.HandleMergeException throws an
> exception, even though it is being called inside a background thread
> generated within the Lucene code and so the exception thrown can never be
> caught and will always crash the application. The code and comments around
> this seem to suggest this is not expected to crash out (maybe due to the port
> from java and java behaves differently from .NET for this?).
> Handling all errors inside our FlushBuffer implementation causes the file to
> become corrupted as the flush is considered a success.
> I think this throw should be removed. We have commented it out and this
> appears to have had no detrimental affect.
--
This message was sent by Atlassian JIRA
(v7.6.14#76016)
