[ 
https://issues.apache.org/jira/browse/SOLR-8587?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15182217#comment-15182217
 ] 

Yonik Seeley commented on SOLR-8587:
------------------------------------

bq. How can a changing index affect the code here. The code uses an IndexReader 
instance, and Lucene doesn't delete index files until the last reader is closed

On the contrary, lucene has pretty much always deleted (or tried to delete) 
files that are not part of the most recent commit (i.e. not referenced by the 
latest segments_N).  In UNIX, we count on the fact that any files that are 
still open are still usable (even if they are no longer reachable from the 
directory).

It's easy to reproduce this...  follow the first few steps in the tutorial 
http://yonik.com/solr-tutorial/
through the first document add.  Then wait >15sec for the auto hard commit to 
kick in.  Then check /solr/admin/cores and the exception will appear because 
the index files from the currently open reader will no longer be in the 
directory.


> Add segments file information to core admin status
> --------------------------------------------------
>
>                 Key: SOLR-8587
>                 URL: https://issues.apache.org/jira/browse/SOLR-8587
>             Project: Solr
>          Issue Type: Improvement
>            Reporter: Shai Erera
>            Assignee: Shai Erera
>             Fix For: 5.5, master
>
>         Attachments: SOLR-8587.patch, SOLR-8587.patch
>
>
> Having the index's segments file name returned by CoreAdminHandler STATUS can 
> be useful. The info I'm thinking about is the segments file name and its 
> size. If you record that from time to time, in a case of crisis, when u need 
> to restore the index and may not be sure which copy you need to restore, this 
> tiny piece of info can be very useful, as the segmentsN file records the 
> commit point, and therefore what you core reported and what you see at hand 
> can help you make a safer decision.
> I also think it's useful info in general, e.g. probably even more than 
> 'version', and it doesn't add much complexity to the handler or the response.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org

Reply via email to