[
https://issues.apache.org/jira/browse/SOLR-3033?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13198076#comment-13198076
]
Hoss Man commented on SOLR-3033:
--------------------------------
bq. Without a way to declare a default in solrconfig.xml, the user has no way
to use this parameter should a backup be triggered by "backupAfter".
right -- my point is we already have a convention for specifying "default
params for a request handler" but your patch doesn't use that convention.
bq. We don't have a <defaults /> section for request parameters, do we?
Any request handler that subclasses RequestHandlerBase automatically gets
defaults applied when handleRequest is called if they are specified in the
configs (the syntax isn't "<defaults />" it's "<lst
name="defaults">...</lst><lst name="appends">...</lst><lst
name="invariants">...</lst>)
bq. If we kept it as a request-param only, but then let the user specify
defaults, would that create a legal <defaults /> and <invariants /> section
nested within <master /> and <slave />, so users can specify defaults for each?
I'm not sure that would really make sense .. what if an instances was acting as
a repeater so it's both a master and a slave? if you told it to create a
backup, how many would it keep if there was a differnet value specified in the
master/slave sections?
I think maybe you've hit the nail on the head here...
{quote}
And looking at the available request parameters, we probably wouldn't want
defaults for any of them
...
This makes me wonder if my first try was a mistake. Possibly this should only
be an init-param.
{quote}
So perhaps the way forward is...
* keep the "numberToKeep" request param around for backcompat with Solr 3.5 for
people who want to manually specify it when triggering command=backups
* add a new init param for ReplicationHandler to specify how many backups to
keep when backups are made -- the name for this new param should probably _not_
be numberToKeep (suggestion: "maxNumberOfBackups") because:
** we need a name that clarifies it's specific to backups
** we want a name that is distinct from the request param so in docs it's clear
which one is being refered to
* document clearly the interaction between the maxNumberOfBackups init param
and the numberToKeep request param (suggestion: "the numberToKeep request param
can be used with the backup command unless the maxNumberOfBackups init param
has been specified on the handler -- in which case maxNumberOfBackups is always
used and attempts to use the numberToKeep request param will cause an error"
what do you think?
> "numberToKeep" on replication handler does not work with "backupAfter"
> ----------------------------------------------------------------------
>
> Key: SOLR-3033
> URL: https://issues.apache.org/jira/browse/SOLR-3033
> Project: Solr
> Issue Type: Bug
> Components: replication (java)
> Affects Versions: 3.5
> Environment: openjdk 1.6, linux 3.x
> Reporter: Torsten Krah
> Attachments: SOLR-3033.patch
>
>
> Configured my replication handler like this:
> <requestHandler name="/replication" class="solr.ReplicationHandler" >
> <lst name="master">
> <str name="replicateAfter">startup</str>
> <str name="replicateAfter">commit</str>
> <str name="replicateAfter">optimize</str>
> <str
> name="confFiles">elevate.xml,schema.xml,spellings.txt,stopwords.txt,stopwords_de.txt,stopwords_en.txt,synonyms_de.txt,synonyms.txt</str>
> <str name="backupAfter">optimize</str>
> <str name="numberToKeep">1</str>
> </lst>
> </requestHandler>
> So after optimize a snapshot should be taken, this works. But numberToKeep is
> ignored, snapshots are increasing with each call to optimize and are kept
> forever. Seems this settings have no effect.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
