[
https://issues.apache.org/jira/browse/SOLR-1781?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12836519#action_12836519
]
Noble Paul commented on SOLR-1781:
----------------------------------
The problem is that while you are trying to delete the original index, there
may be requests in pipleline which uses the old index. If the index files are
deleted those requests may fail.
> Replication index directories not always cleaned up
> ---------------------------------------------------
>
> Key: SOLR-1781
> URL: https://issues.apache.org/jira/browse/SOLR-1781
> Project: Solr
> Issue Type: Bug
> Components: replication (java)
> Affects Versions: 1.4
> Environment: Windows Server 2003 R2, Java 6b18
> Reporter: Terje Sten Bjerkseth
> Assignee: Noble Paul
> Fix For: 1.5
>
> Attachments:
> 0001-Replication-does-not-always-clean-up-old-directories.patch
>
>
> We had the same problem as someone described in
> http://mail-archives.apache.org/mod_mbox/lucene-solr-user/201001.mbox/%3c222a518d-ddf5-4fc8-a02a-74d4f232b...@snooth.com%3e.
> A partial copy of that message:
> We're using the new replication and it's working pretty well. There's
> one detail I'd like to get some more information about.
> As the replication works, it creates versions of the index in the data
> directory. Originally we had index/, but now there are dated versions
> such as index.20100127044500/, which are the replicated versions.
> Each copy is sized in the vicinity of 65G. With our current hard drive
> it's fine to have two around, but 3 gets a little dicey. Sometimes
> we're finding that the replication doesn't always clean up after
> itself. I would like to understand this better, or to not have this
> happen. It could be a configuration issue.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
