You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@lucenenet.apache.org by "Laimonas Simutis (JIRA)" <ji...@apache.org> on 2019/01/25 14:41:00 UTC
[jira] [Reopened] (LUCENENET-603) ConcurrentMergeScheduler crashes
the application if a transient error occurs
[ https://issues.apache.org/jira/browse/LUCENENET-603?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Laimonas Simutis reopened LUCENENET-603:
----------------------------------------
[~laura.m.nash] I saw your comment on [https://github.com/apache/lucenenet/pull/214] about this. Putting this ticket and PR together makes it much more clear what's going on. Thank you.
Reopening and setting the affects version to 4.8 since you seem to be seeing it there. We will investigate if we deviated from the java port and why that throw exists.
> 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
> 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)