[jira] Created: (LUCENE-1397) When BG merge hits an exception, optimize sometimes throws an IOException missing the root cause

classic Classic list List threaded Threaded
3 messages Options
Reply | Threaded
Open this post in threaded view
|

[jira] Created: (LUCENE-1397) When BG merge hits an exception, optimize sometimes throws an IOException missing the root cause

Sebastian Nagel (Jira)
When BG merge hits an exception, optimize sometimes throws an IOException missing the root cause
------------------------------------------------------------------------------------------------

                 Key: LUCENE-1397
                 URL: https://issues.apache.org/jira/browse/LUCENE-1397
             Project: Lucene - Java
          Issue Type: Bug
          Components: Index
    Affects Versions: 2.4
            Reporter: Michael McCandless
            Assignee: Michael McCandless
            Priority: Minor
             Fix For: 2.4, 2.9



When IndexWriter.optimize() is called, ConcurrentMergeScheduler will
run the requested merges with background threads and optimize() will
wait for these merges to complete.

If a merge hits an exception, it records the root cause exception such
that optimize can then retrieve this root cause and throw its own
exception, with the root cause.

But there is a bug: sometimes, the fact that an exception occurred on
a merge is recorded, but the root cause is missing.  In this cause,
optimize() still throws an exception (correctly indicating that the
optimize() has not finished successfully), but it's not helpful
because it's missing the root cause.  You must then go find the root
cause in the JRE's stderr logs.

This has hit a few users on this lists, most recently:

  http://www.nabble.com/Background-merge-hit-exception-td19540409.html#a19540409

I found the isssue, and finally got a unit test to intermittently show
it.  It's a simple thread safety issue: in a finally clause in
IndexWriter.merge we record the fact that the merge hit an exception
before actually setting the root cause, and then only in
ConcurrentMergeScheduler's exception handler do we set the root
cause.  If the optimize thread is scheduled in between these two, it
can throw an exception missing its root cause.

The fix is straightforward.  I plan to commit to 2.4 & 2.9.


--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.


---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

[jira] Updated: (LUCENE-1397) When BG merge hits an exception, optimize sometimes throws an IOException missing the root cause

Sebastian Nagel (Jira)

     [ https://issues.apache.org/jira/browse/LUCENE-1397?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Michael McCandless updated LUCENE-1397:
---------------------------------------

    Attachment: LUCENE-1397.patch

Attached patch.  I plan to commit in a day or so, and then roll another RC.

> When BG merge hits an exception, optimize sometimes throws an IOException missing the root cause
> ------------------------------------------------------------------------------------------------
>
>                 Key: LUCENE-1397
>                 URL: https://issues.apache.org/jira/browse/LUCENE-1397
>             Project: Lucene - Java
>          Issue Type: Bug
>          Components: Index
>    Affects Versions: 2.4
>            Reporter: Michael McCandless
>            Assignee: Michael McCandless
>            Priority: Minor
>             Fix For: 2.4, 2.9
>
>         Attachments: LUCENE-1397.patch
>
>
> When IndexWriter.optimize() is called, ConcurrentMergeScheduler will
> run the requested merges with background threads and optimize() will
> wait for these merges to complete.
> If a merge hits an exception, it records the root cause exception such
> that optimize can then retrieve this root cause and throw its own
> exception, with the root cause.
> But there is a bug: sometimes, the fact that an exception occurred on
> a merge is recorded, but the root cause is missing.  In this cause,
> optimize() still throws an exception (correctly indicating that the
> optimize() has not finished successfully), but it's not helpful
> because it's missing the root cause.  You must then go find the root
> cause in the JRE's stderr logs.
> This has hit a few users on this lists, most recently:
>   http://www.nabble.com/Background-merge-hit-exception-td19540409.html#a19540409
> I found the isssue, and finally got a unit test to intermittently show
> it.  It's a simple thread safety issue: in a finally clause in
> IndexWriter.merge we record the fact that the merge hit an exception
> before actually setting the root cause, and then only in
> ConcurrentMergeScheduler's exception handler do we set the root
> cause.  If the optimize thread is scheduled in between these two, it
> can throw an exception missing its root cause.
> The fix is straightforward.  I plan to commit to 2.4 & 2.9.

--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.


---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

[jira] Resolved: (LUCENE-1397) When BG merge hits an exception, optimize sometimes throws an IOException missing the root cause

Sebastian Nagel (Jira)
In reply to this post by Sebastian Nagel (Jira)

     [ https://issues.apache.org/jira/browse/LUCENE-1397?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Michael McCandless resolved LUCENE-1397.
----------------------------------------

    Resolution: Fixed

Committed revision 698025 (trunk) and 698026 (2.4)

> When BG merge hits an exception, optimize sometimes throws an IOException missing the root cause
> ------------------------------------------------------------------------------------------------
>
>                 Key: LUCENE-1397
>                 URL: https://issues.apache.org/jira/browse/LUCENE-1397
>             Project: Lucene - Java
>          Issue Type: Bug
>          Components: Index
>    Affects Versions: 2.4
>            Reporter: Michael McCandless
>            Assignee: Michael McCandless
>            Priority: Minor
>             Fix For: 2.4, 2.9
>
>         Attachments: LUCENE-1397.patch
>
>
> When IndexWriter.optimize() is called, ConcurrentMergeScheduler will
> run the requested merges with background threads and optimize() will
> wait for these merges to complete.
> If a merge hits an exception, it records the root cause exception such
> that optimize can then retrieve this root cause and throw its own
> exception, with the root cause.
> But there is a bug: sometimes, the fact that an exception occurred on
> a merge is recorded, but the root cause is missing.  In this cause,
> optimize() still throws an exception (correctly indicating that the
> optimize() has not finished successfully), but it's not helpful
> because it's missing the root cause.  You must then go find the root
> cause in the JRE's stderr logs.
> This has hit a few users on this lists, most recently:
>   http://www.nabble.com/Background-merge-hit-exception-td19540409.html#a19540409
> I found the isssue, and finally got a unit test to intermittently show
> it.  It's a simple thread safety issue: in a finally clause in
> IndexWriter.merge we record the fact that the merge hit an exception
> before actually setting the root cause, and then only in
> ConcurrentMergeScheduler's exception handler do we set the root
> cause.  If the optimize thread is scheduled in between these two, it
> can throw an exception missing its root cause.
> The fix is straightforward.  I plan to commit to 2.4 & 2.9.

--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.


---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]