lucene-dev mailing list archives

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

    [ 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: dev-unsubscribe@lucene.apache.org
For additional commands, e-mail: dev-help@lucene.apache.org


Mime
View raw message