[
https://issues.apache.org/jira/browse/SOLR-8587?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15182197#comment-15182197
]
Shai Erera commented on SOLR-8587:
----------------------------------
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
(within the same process). Also, if that IR instance says its commit point
references a certain segments_N file, and some other process then goes and
deletes index files, how can that IR instance work afterwards? I guess I'm
missing something here.
Also, {{CoreAdminHandler.getCoreStatus()}} computes the size of the directory
immediately after, although it doesn't use an IR instance to do that, but
still, can't it fail while listing the directory and then attempt to compute
file lengths? How is that different then computing the file length of the
segments_N?
The length is important so that you can make some comparisons to e.g. one
{{segments_37}} vs another (in a backup maybe), to know if one may be corrupt.
Maybe not the best use case, but I think that it's an important piece of
information. Before we remove it I'd like to get to the bottom of the
exception, to ensure we don't miss something here, or there's a potential bug
lurking in the code, and removing that particular code will just hide it again.
If my assumptions are incorrect, and however that {{LukeRequestHandler}} works
is not the usual workflow with Lucene's IndexWriter/Reader, I don't mind
catching the exception and reporting size 0 for that file. But I think it's
unhealthy if the system can have an IR which references files that may be
deleted ...
> 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: [email protected]
For additional commands, e-mail: [email protected]
