[ https://issues.apache.org/jira/browse/LUCENE-7700?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15884313#comment-15884313 ]
Dawid Weiss commented on LUCENE-7700: ------------------------------------- No rush. I've corrected a few javadocs (github branch) and the tests and precommit pass for me. > Move throughput control and merge aborting out of IndexWriter's core? > --------------------------------------------------------------------- > > Key: LUCENE-7700 > URL: https://issues.apache.org/jira/browse/LUCENE-7700 > Project: Lucene - Core > Issue Type: Improvement > Reporter: Dawid Weiss > Assignee: Dawid Weiss > Priority: Minor > Attachments: LUCENE-7700.patch, LUCENE-7700.patch > > > Here is a bit of a background: > - I wanted to implement a custom merging strategy that would have a custom > i/o flow control (global), > - currently, the CMS is tightly bound with a few classes -- MergeRateLimiter, > OneMerge, IndexWriter. > Looking at the code it seems to me that everything with respect to I/O > control could be nicely pulled out into classes that explicitly control the > merging process, that is only MergePolicy and MergeScheduler. By default, one > could even run without any additional I/O accounting overhead (which is > currently in there, even if one doesn't use the CMS's throughput control). > Such refactoring would also give a chance to nicely move things where they > belong -- job aborting into OneMerge (currently in RateLimiter), rate limiter > lifecycle bound to OneMerge (MergeScheduler could then use per-merge or > global accounting, as it pleases). > Just a thought and some initial refactorings for discussion. -- This message was sent by Atlassian JIRA (v6.3.15#6346) --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org