You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@lucene.apache.org by "Shawn Heisey (JIRA)" <ji...@apache.org> on 2018/03/28 15:13:00 UTC
[jira] [Commented] (SOLR-12156) "" in
solrconfig.xml similar to ""
[ https://issues.apache.org/jira/browse/SOLR-12156?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16417506#comment-16417506 ]
Shawn Heisey commented on SOLR-12156:
-------------------------------------
bq. maxMergedSegmentMB (same as in TieredMergePolicy)
As far as I know, forceMerge doesn't pay attention to a max segment size. I'm prepared to be wrong about this, but that is my understanding. The "force" in the operation name indicates that you're asking it to do something it normally doesn't do.
bq. maxOptimizeSegments (same as in solrjClient.optimize)
This is the only one of these settings that really makes sense to me ... but it's already possible when you DO the optimize, so a new config mechanism is unnecessary.
bq. expungeDeletes (true/false)
Isn't this the entire point of an optimize to begin with? I'm not sure this is even an option on Lucene's forceMerge. I think it's an option for commit.
bq. optimizeTimeout(in minutes)
As far as I know, forceMerge doesn't offer any mechanism to abort after a timeout. Solr shouldn't expose config options that don't exist on the underlying code.
bq. disableExlicitOptimize (disable all solrClient call to optimize )
This is already possible with an update processor. It's been around for a long time.
https://lucene.apache.org/solr/7_0_0//solr-core/org/apache/solr/update/processor/IgnoreCommitOptimizeUpdateProcessorFactory.html
bq. optimizeJobCron - associated to disableExlicitOptimize where optimization can be carried out at a maintenance period defined by the cron expression.
You're going to run into major opposition for this one. Solr should *NEVER* make any changes to the index that are NOT triggered explicitly by user action. Especially not something that can quite literally take hours and severely impact performance.
At the moment, there is precisely one feature that can make changes separately from an explicit request. It is the document expiration feature, where documents can basically be indexed with information indicating exactly when the system should automatically delete them. It's not quite covered under the "never make changes without user input" umbrella, though -- because when the user indexed the document, they also told Solr when it should be deleted. So it IS triggered by user action, it's just that the operation is delayed.
> "<optimizeConfig>" in solrconfig.xml similar to "<indexConfig>"
> ---------------------------------------------------------------
>
> Key: SOLR-12156
> URL: https://issues.apache.org/jira/browse/SOLR-12156
> Project: Solr
> Issue Type: Wish
> Security Level: Public(Default Security Level. Issues are Public)
> Components: config-api
> Reporter: Indranil Majumder
> Priority: Major
>
> It would be great to have the below config parameters in solrconfig.xml :-
> # maxMergedSegmentMB (same as in TieredMergePolicy)
> # maxOptimizeSegments (same as in solrjClient.optimize( *waitFlush,**waitSearcher* ,{color:#FF0000}*maxSegments*{color}))
> # expungeDeletes (true/false)
> # optimizeTimeout(in minutes)
> # disableExlicitOptimize (disable all solrClient call to optimize )
> ## optimizeJobCron - associated to disableExlicitOptimize where optimization can be carried out at a maintenance period defined by the cron expression.
> This in turn needs to be respected by DirectUpdateHandler2 or any other handler trying to optimize the index
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@lucene.apache.org
For additional commands, e-mail: dev-help@lucene.apache.org