[
https://issues.apache.org/jira/browse/SOLR-6834?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Hoss Man resolved SOLR-6834.
----------------------------
Resolution: Fixed
Fix Version/s: Trunk
Assignee: Hoss Man
> checkIntegrityAtMerge needs removed from example configs & a warning should
> be logged if used
> ---------------------------------------------------------------------------------------------
>
> Key: SOLR-6834
> URL: https://issues.apache.org/jira/browse/SOLR-6834
> Project: Solr
> Issue Type: Task
> Reporter: Hoss Man
> Assignee: Hoss Man
> Fix For: 5.0, Trunk
>
> Attachments: SOLR-6834.patch
>
>
> from the dev@lucene list...
> {quote}
> Subject: Re: Performance hit of Solr checkIntegrityAtMerge
> There are two costs: cpu and i/o.
> The cpu cost is not much anyway but can be made basically trivial by
> using java 8.
> The i/o cost is because the check is not done with any i/o locality to
> the data being merged. so it could be a perf hit for an extremely
> large merge.
> In 5.0 the option is removed: we reworked this computation in merging
> to always have locality and so on, the checking always happens.
> {quote}
> ...but on the 5x branch, the checkIntegrityAtMerge setting (and comments)
> still exist in the example configs, and the SolrIndexConfig code still parses
> it (but does nothing with it since IWC no longer accepts it as an option)
> todo..
> * remove setting form example configs (runk & 5x)
> * update code to check if the setting is used & log a warning that it's now
> ignored
> ** backport this to 5x
> * update code (trunk only) to completely remove parsing of this setting
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
