houserjohn commented on issue #14431: URL: https://github.com/apache/lucene/issues/14431#issuecomment-2803254782
After looking into the suggestions you mentioned, I still believe there is a valid need for a timeout for `forceMergeDeletes`. In the first suggestion, you recommended using two different forceMergeDeletes calls with different targets/blocking behavior. While I think this is a good suggestion, there still is this problem that either the index is too large and the blocking call takes too long for user needs, or not enough deletes are addressed before bringing the index online (as msokolov described). In the second suggestion, it is true that it would be better to do several small merges rather than a large merge. To my understanding, `forceMergeDeletes` does not do several, small merges. However, natural background merges are nonblocking and do not help us address the deletes in the index before it goes online. Additionally, maybe this might answer a question you have, because it did for me. If we decide to implement a timeout in `forceMergeDeletes`, we do not need to be concerned about interrupting the process and corrupting the index because our merges are done atomically. Theoretically, we should be able to stop `forceMergeDeletes` at any point and our index would not be corrupted. Even if we lose all progress on `forceMergeDeletes` after the timeout occurs, we will still give users tighter control over the `forceMergeDeletes` process. -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org --------------------------------------------------------------------- To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org For additional commands, e-mail: issues-h...@lucene.apache.org
