[
https://issues.apache.org/jira/browse/LUCENENET-603?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16753875#comment-16753875
]
Laura Nash commented on LUCENENET-603:
--------------------------------------
No, that isn't the behaviour I am observing. The exception thrown on the
background thread crashes the application. No further activity is possible.
This has been standard behaviour in .NET since 2.0:
[https://docs.microsoft.com/en-us/dotnet/standard/threading/exceptions-in-managed-threads].
I'm not that familiar with Java but I believe it may have different behaviour
for unhandled exceptions in threads which would explain why this code is fine
in the original lucene codebase.
> 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
> Priority: Major
> Labels: easyfix, newbie
>
> 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.3#76005)
