lucenenet-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Laimonas Simutis (JIRA)" <>
Subject [jira] [Commented] (LUCENENET-603) ConcurrentMergeScheduler crashes the application if a transient error occurs
Date Sat, 26 Jan 2019 13:05:00 GMT


Laimonas Simutis commented on LUCENENET-603:

[~laura.m.nash] I spent some more time looking at this and checked what the original code
base, and we did not deviate from it in that original Lucene throws the exception there
too. I checked the 4_x branch on lucene and this is what it looks:


Later revisions of that file remove the sleep and try/catch in there just like we have in

Do you have any more info from your end how to reproduce the issue you are running into? If
yo are observing exceptions on the background thread and the background merge dies, another
merge eventually should run again until it succeeds. Is this not the behavior you are observing?

> ConcurrentMergeScheduler crashes the application if a transient error occurs
> ----------------------------------------------------------------------------
>                 Key: LUCENENET-603
>                 URL:
>             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

View raw message