Return-Path: X-Original-To: apmail-lucene-dev-archive@www.apache.org Delivered-To: apmail-lucene-dev-archive@www.apache.org Received: from mail.apache.org (hermes.apache.org [140.211.11.3]) by minotaur.apache.org (Postfix) with SMTP id 0C503922F for ; Wed, 1 Feb 2012 19:33:23 +0000 (UTC) Received: (qmail 70893 invoked by uid 500); 1 Feb 2012 19:33:21 -0000 Delivered-To: apmail-lucene-dev-archive@lucene.apache.org Received: (qmail 70439 invoked by uid 500); 1 Feb 2012 19:33:20 -0000 Mailing-List: contact dev-help@lucene.apache.org; run by ezmlm Precedence: bulk List-Help: List-Unsubscribe: List-Post: List-Id: Reply-To: dev@lucene.apache.org Delivered-To: mailing list dev@lucene.apache.org Received: (qmail 70431 invoked by uid 99); 1 Feb 2012 19:33:20 -0000 Received: from athena.apache.org (HELO athena.apache.org) (140.211.11.136) by apache.org (qpsmtpd/0.29) with ESMTP; Wed, 01 Feb 2012 19:33:20 +0000 X-ASF-Spam-Status: No, hits=-2000.0 required=5.0 tests=ALL_TRUSTED,T_RP_MATCHES_RCVD X-Spam-Check-By: apache.org Received: from [140.211.11.116] (HELO hel.zones.apache.org) (140.211.11.116) by apache.org (qpsmtpd/0.29) with ESMTP; Wed, 01 Feb 2012 19:33:18 +0000 Received: from hel.zones.apache.org (hel.zones.apache.org [140.211.11.116]) by hel.zones.apache.org (Postfix) with ESMTP id A78AB184A12 for ; Wed, 1 Feb 2012 19:32:58 +0000 (UTC) Date: Wed, 1 Feb 2012 19:32:58 +0000 (UTC) From: "Hoss Man (Commented) (JIRA)" To: dev@lucene.apache.org Message-ID: <1780039042.3861.1328124778687.JavaMail.tomcat@hel.zones.apache.org> In-Reply-To: <851208854.33704.1326355659454.JavaMail.tomcat@hel.zones.apache.org> Subject: [jira] [Commented] (SOLR-3033) "numberToKeep" on replication handler does not work with "backupAfter" MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-JIRA-FingerPrint: 30527f35849b9dde25b450d4833f0394 [ 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 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 "" it's ".........) bq. If we kept it as a request-param only, but then let the user specify defaults, would that create a legal and section nested within and , 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: > > > startup > commit > optimize > elevate.xml,schema.xml,spellings.txt,stopwords.txt,stopwords_de.txt,stopwords_en.txt,synonyms_de.txt,synonyms.txt > optimize > 1 > > > 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