lucene-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Hoss Man (Commented) (JIRA)" <>
Subject [jira] [Commented] (SOLR-3033) "numberToKeep" on replication handler does not work with "backupAfter"
Date Wed, 01 Feb 2012 19:32:58 GMT


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

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...

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.

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:
>             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:!default.jspa
For more information on JIRA, see:


To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message