[
https://issues.apache.org/jira/browse/SOLR-3033?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13197387#comment-13197387
]
Hoss Man commented on SOLR-3033:
--------------------------------
James: two things to think about.
1) when adding new test configs, try to keep them as minimal as possible, so
the only things in them are things that *have* to be there for the purposes of
the test.
2) there are really two types of "params" when dealing with request handlers --
init params (ie: things in the body of the requestHandler tag in
solrconfig.xml) and request params (things passed to the handler when it is
executed. via RequestHandlerBase many request handlers support the idea of
_init_ params named "defaults", "invariants" and "appends" which can contain
sub-params that are consulted when parsing/processing _request_ params in
handleRequest.
In the case of the "numberToKeep", this is already a _request_ param, and
ReplicationHandler already subclasses RequestHandlerBase which means people can
define a "defaults" section in their ReplicationHandler config so any requests
to "http://master_host:port/solr/replication?command=backup"; get that value
automaticly. but your patch seems to add support for an _init_ param with the
same name: which raises questions like "what happens if i specify differnet
values for numberToKeep in init params and in invariant params?"
it seems like the crux of the problem is that if you use the "backupAfter"
option, the code path to create the backup bypasses a lot of the logic that is
normally used when a backup command is processed via handleRequest. 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? perhaps it could be something as straight
forward as changing the meat of getEventListener to look like...
{code}
SolrQueryRequest req = new LocalSolrRequest(core ...);
try {
RequestHandler.this.handleRequest(req, new SolrQueryResponse());
} finally {
req.close();
}
{code}
what do you think?
> numberToKeep on replication handler does not work - snapshots are increasing
> beyond configured maximum
> ------------------------------------------------------------------------------------------------------
>
> 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]
