Yes, I rewrote the shell scripts into java for more control and made them callable via a web service. So there is the normal commit call and a snapshooter call. I will check these in soon. Then when a snapshot is completed, the slave machines snappuller is called. The cron is implemented using a hack of Resin's CronResource. Not sure if there is a more generic way to do this using non-Resin code.
----- Original Message ---- From: Bill Au <[EMAIL PROTECTED]> To: solr-dev@lucene.apache.org Sent: Monday, April 24, 2006 7:56:51 AM Subject: Re: commit The snapshooter can be run manaully. So one can disable the postCommit listener and run it manually to take snapshots at specific times rather than after every commit. Bill On 4/23/06, Yonik Seeley <[EMAIL PROTECTED]> wrote: > > Hi Jason, > > On 4/21/06, jason rutherglen <[EMAIL PROTECTED]> wrote: > > Is there a way to decouple the snapshot creation from the index > reloading currently? If not I was going to build it in. We have a 700 meg > index, so creating a snapshot basically copies that, and after several > snapshots takes up a lot of storage. > > It may not be taking up as much space as you think (it really depends). > Only the index segments that were changed take up new space... the > other index segments are all hard linked across all of the snapshots > to the same file. > > > Sometimes I just want to see a change show up on the master, sometimes > I want to create a snapshot for the slave servers. This was very confusing > when I first started using Solr. > > I've had the idea of a "quiet" commit in the back of my mind for a > while... for when someone just wants to checkpoint their indexing > work, but not force a new index reader to be opened, or have snapshots > taken. This can also be useful if you are rebuilding an index from > scratch and you don't want a snapshot of an incomplete index being > replicated out to the slaves. > > Your idea is another variant, where you want some things done, but not > others. > > Here are all the variants (a snapshot is taken by a commit listener): > a) don't call listeners, don't open new indexreader > b) don't call listeners, open new reader > c) call listeners, don't open new reader > d) call listeners, open new reader // the current behavior > > I think (a) could be very useful, (b) could be useful to locally > sanity check an index, and > (c) is probably not useful. > > Could you open a JIRA bug to track this? > > -Yonik >
