lucene-dev mailing list archives

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

    [ https://issues.apache.org/jira/browse/SOLR-3033?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13197948#comment-13197948
] 

James Dyer commented on SOLR-3033:
----------------------------------

{quote}
So instead of adding an init param version of numberToKeep, perhaps it owuld be better if
the "backupAfter" codepath followed the same code path as handleRequest as much as possible?
{quote}
It wasn't so much my intention to add an init-param but to make a way to give a default value
for this in solrconfig.xml as you can for other handlers.  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".  

When I looked at this, it didn't seem that ReplicationHandler follows the normal rules.  We
don't have a <defaults /> section for request parameters, do we?  And looking at the
available request parameters, we probably wouldn't want defaults for any of them  (see http://wiki.apache.org/solr/SolrReplication#HTTP_API).
 

This makes me wonder if my first try was a mistake.  Possibly this should _only_ be an init-param.
 This would let users configure how many to keep on the Master, and how many to keep on the
Slave.  We don't let users change poll intervals with request params, so why let them change
the archive policy with request params?

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 don't have a strong feeling on this and would change the patch to work any way you thought
best.  Somehow it seems that "numberToKeep" needs to have a default setting somewhere, somehow,
so it will work with "backupAfter".
                
> "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