Thanks for the reply. I'm at home right now, or I'd try this myself, but is the suggestion that two optimize() calls in a row would resolve the issue? The process in question is a JVM devoted entirely to harvesting, calls optimize() then shuts down.
The least processor intensive way of triggering this behaviour is desirable... perhaps a commit()? But I wouldn't have expected that to trigger a write. On 17 May 2011 10:20, Chris Hostetter <hossman_luc...@fucit.org> wrote: > > : http://code.google.com/p/solr-geonames/wiki/DeveloperInstall > : "It's worth noting that the build has also been run on Mac and Solaris > now, > : and the Solr index is about half the size. We suspect the optimize() call > in > : Embedded Solr is not working correctly under Windows." > : > : We've observed that Windows leaves lots of segments on disk and takes up > : twice the volume as the other OSs. Perhaps file locking or something > > The problem isn't that "optimize" doesn't work on windows, the problem is > that windows file semantics won't let files be deleted while there are > open file handles -- so Lucene's Directory behavior is to leave the files > on disk, and try to clean them up later. (on the next write, or next > optimize call) > > > -Hoss >
