[
https://issues.apache.org/jira/browse/LUCENE-1270?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Michael McCandless resolved LUCENE-1270.
----------------------------------------
Resolution: Fixed
Thanks Stu!
> After IW.addIndexesNoOptimize, IW.close may hang
> ------------------------------------------------
>
> Key: LUCENE-1270
> URL: https://issues.apache.org/jira/browse/LUCENE-1270
> Project: Lucene - Java
> Issue Type: Bug
> Components: Index
> Affects Versions: 2.3, 2.3.1
> Reporter: Michael McCandless
> Assignee: Michael McCandless
> Priority: Minor
> Fix For: 2.3.2, 2.4
>
> Attachments: LUCENE-1270.patch
>
>
> Spinoff from here:
>
> http://mail-archives.apache.org/mod_mbox/lucene-java-user/200804.mbox/[EMAIL
> PROTECTED]
> The addIndexesNoOptimize method first merges eligible segments
> according to the MergePolicy, and then copies over one by one any
> remaining "external" segments.
> That copy can possibly (rather rarely) result in new merges becoming
> eligible because its size can change if the index being added was
> created with autoCommit=false.
> However, we fail to then invoke the MergeScheduler to run these
> merges. As a result, in close, where we wait until all running and
> pending merges complete, we will never return.
> The fix is simple: invoke the merge scheduler inside
> copyExternalSegments() if any segments were copied. I also added
> defensive invocation of the merge scheduler during close, just in case
> other code paths could allow for a merge to be added to the pending
> queue but not scheduled.
--
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: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
