[
https://issues.apache.org/jira/browse/SOLR-617?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12627881#action_12627881
]
Yonik Seeley commented on SOLR-617:
-----------------------------------
#1 and #2 can both lead to starvation. I think the default should finish
grabbing an index even if a newer version is available.
bq. Here, the onus of keeping a commit point for reliable replication will fall
on the user supplying configuration
If we can make it such that it just works, regardless of network speed, index
size, etc, then I think we should. A reservation mechanism would easily enable
this.
> Allow configurable deletion policy
> ----------------------------------
>
> Key: SOLR-617
> URL: https://issues.apache.org/jira/browse/SOLR-617
> Project: Solr
> Issue Type: New Feature
> Components: search, update
> Affects Versions: 1.4
> Reporter: Noble Paul
> Assignee: Shalin Shekhar Mangar
> Priority: Minor
> Fix For: 1.4
>
> Attachments: 617.patch, solr-617.patch
>
>
> Lucene API provides means to configure deletion policy. Solr should be able
> to expose it through configuration in solrconfig.xml. Moreover the new
> replication (SOLR-561) strategy is going to rely on this .
> I propose the configuration go into the <mainIndex> section
> sample configuration
> {code:xml|title=solrconfig.xml}
> <mainIndex>
> <!-- configure deletion policy here-->
> <deletionPolicy>
> <!-- Store only the commits with optimize.Non optimized commits will
> get deleted by lucene when
> the last IndexWriter/IndexReader using this commit point is
> closed -->
> <keepOptimizedOnly>true</keepOptimizedOnly>
> <!--Maximum no: of commit points stored . Older ones will be cleaned
> when they go out of scope-->
> <maxCommitsToKeep></maxCommitsToKeep>
> <!-- max age of a stored commit-->
> <maxCommitAge></maxCommitAge>
> </deletionPolicy>
>
> </mainIndex>
> {code}
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
