[
https://issues.apache.org/jira/browse/LUCENE-5080?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13694911#comment-13694911
]
Shai Erera commented on LUCENE-5080:
------------------------------------
The only concern I have is that someone may want to dynamically set that based
on some overall application workload. Since MS is on LiveIWC, it's fine cause
you can reset to a new CMS instance. But in that case what will happen to the
other CMS which loops until IW has no more merges? Is that ok?
Maybe instead we can have CMS.reset(int,int) to avoid that case?
> CMS setters cannot work unless you setMaxMergeCount before you
> setMaxThreadCount
> --------------------------------------------------------------------------------
>
> Key: LUCENE-5080
> URL: https://issues.apache.org/jira/browse/LUCENE-5080
> Project: Lucene - Core
> Issue Type: Bug
> Reporter: Robert Muir
>
> {code}
> public void setMaxThreadCount(int count) {
> ...
> if (count > maxMergeCount) {
> throw new IllegalArgumentException("count should be <= maxMergeCount (=
> " + maxMergeCount + ")");
> }
> {code}
> but:
> {code}
> public void setMaxMergeCount(int count) {
> ...
> if (count < maxThreadCount) {
> throw new IllegalArgumentException("count should be >= maxThreadCount
> (= " + maxThreadCount + ")");
> }
> {code}
> So you must call them in a magical order. I think we should nuke these
> setters and just have a CMS(int,int)
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
