hm okay, reasonable :) never used it, but maybe a pointer into the right direction? http://wiki.apache.org/solr/DataImportHandler#Scheduling
On Wed, Feb 16, 2011 at 2:27 PM, Renaud Delbru <renaud.del...@deri.org> wrote: > Mainly technical administration effort. > > We are trying to have a solr packaging that > - minimises the effort to deploy the system on a machine. > - reduces errors when deploying > - centralised the logic of the Solr system > > Ideally, we would like to have a central place (e.g., solrconfig) where the > logic of the system is configured. > In that case, the system administrator does not have to bother with a long > list of tasks and checkpoints every time we need to release a new version of > the solr system, or extend our clusters. He should just have to take the new > release, ship it on a machine, and start up solr. > -- > Renaud Delbru > > On 16/02/11 13:15, Stefan Matheis wrote: >> >> Renaud, >> >> just because i'm interested in .. what are your concerns about using >> cron for that? >> >> Stefan >> >> On Wed, Feb 16, 2011 at 2:12 PM, Renaud Delbru<renaud.del...@deri.org> >> wrote: >>> >>> Hi, >>> >>> We would like to trigger an optimise every x hours. From what I can see, >>> there is nothing in Solr (3.1-SNAPSHOT) that enables to do such a thing. >>> We have a master-slave configuration. The masters are tuned for fast >>> indexing (large merge factor). However, for the moment, the master index >>> is >>> replicated as it is to the slaves, and therefore it does not provide very >>> fast query time. >>> Our idea was >>> - to configure the replication so that it only happens after an optimise, >>> and >>> - schedule a partial optimise in order to reduce the number of segments >>> every x hours for faster querying. >>> We do not want to rely on cron job for executing the partial optimise >>> every >>> x hours, but we would prefer to configure this directly within the solr >>> config. >>> >>> Our first idea was to create a SolrEventListener, that will be postCommit >>> triggered, and that will be in charge of executing an optimise at regular >>> time interval. Is this a good approach ? Or is there other solutions to >>> achieve this ? >>> >>> Thanks, >>> -- >>> Renaud Delbru >>> > >
