As I had pointed out in my first reply to this thread, you had a directory named temp-snapshot.20070816120113 in your data directory on the slave. Snapinstaller was mistakenly treating that as the lastest snapshot and was installing that every time it was called. Snapinstaller didn't trigger a commit since the same snapshot had already been installed.
> latest snapshot /opt/solr/data/temp-snapshot.20070816120113 already > installed I have open a bug to improve snapinstaller: http://issues.apache.org/jira/browse/SOLR-346 Bill On 9/6/07, Matthew Runo <[EMAIL PROTECTED]> wrote: > > Well, I've been playing around with it (removed all the snapshots, > restarted tomcat) and it seems like it works now.. maybe. > > I was noticing that search2 and search3, the slaves, had searchers > that had been opened several days ago - when we do several 100 > commits and 2 optimizes on search1, the master, every day. > > +--------------------------------------------------------+ > | Matthew Runo > | Zappos Development > | [EMAIL PROTECTED] > | 702-943-7833 > +--------------------------------------------------------+ > > > On Sep 6, 2007, at 12:37 PM, Yonik Seeley wrote: > > > On 9/6/07, Matthew Runo <[EMAIL PROTECTED]> wrote: > >> The thing is that a new searcher is not opened if I look in the > >> stats.jsp page. The index version never changes. > > > > The index version is read from the index... hence if the lucene index > > doesn't change (even if a ew snapshot was taken), the version won't > > change even if a new searcher was opened. > > > > Is the problem on the master side now since it looks like the slave is > > pulling a temp-snapshot? > > > > -Yonik > > > >
