[
https://issues.apache.org/jira/browse/SOLR-16866?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17847422#comment-17847422
]
Michael Gibney commented on SOLR-16866:
---------------------------------------
Thanks for catching/fixing this.
It definitely makes sense to include this in 9.6.1, but fwiw I don't think the
actual behavior will have changed with 9.6.0, functionally, for Windows users.
IIUC {{isSubPath()}} would always return {{false}} on Windows, both before and
after [PR #2349|https://github.com/apache/solr/pull/2349]. The functional
consequence of this is that both before and after that PR, on Windows anytime a
cache entry is closed it would be deleted immediately, regardless of whether it
has yet-unclosed subpaths. This was the status quo before [PR
#2349|https://github.com/apache/solr/pull/2349] for both Windows and
non-Windows, with arbitrary HashMap iteration order causing parent directories
to be deleted before their child entries, leading NoSuchFileExceptions to be
logged, e.g. on core removal.
So although 9.6.0 fixed the behavior for non-Windows, the latent path-separator
issue prevented it from being fixed for Windows, and the added test surfaced
the issue for Windows (as well as demonstrating that the issue is fixed for
non-Windows).
> CachingDirectoryFactory Throwing Error When Closing
> ---------------------------------------------------
>
> Key: SOLR-16866
> URL: https://issues.apache.org/jira/browse/SOLR-16866
> Project: Solr
> Issue Type: Bug
> Affects Versions: 9.2.1
> Reporter: Stefan Pieper
> Assignee: Michael Gibney
> Priority: Major
> Labels: core
> Fix For: 9.6
>
> Attachments: solr.blueprint_gnylctsgemcz_users.log
>
> Time Spent: 3h 40m
> Remaining Estimate: 0h
>
> Observed occasional ERROR log entries when {{CachingDirectryFactory#close()}}
> is called. The respective snippet from the log is this:
> {noformat}
> 2023-07-06 08:43:37.618 DEBUG (qtp212011969-1801) [
> blueprint_gnylctsgemcz_users] o.a.s.c.CachingDirectoryFactory Removing
> directory after core close: /var/solr/data/blueprint_gnylctsgemcz_users/data
> 2023-07-06 08:43:37.620 DEBUG (qtp212011969-1801) [
> blueprint_gnylctsgemcz_users] o.a.s.c.CachingDirectoryFactory Removing
> directory after core close:
> /var/solr/data/blueprint_gnylctsgemcz_users/data/index
> 2023-07-06 08:43:37.620 ERROR (qtp212011969-1801) [
> blueprint_gnylctsgemcz_users] o.a.s.c.CachingDirectoryFactory Error removing
> directory => java.nio.file.NoSuchFileException:
> /var/solr/data/blueprint_gnylctsgemcz_users/data/index
> java.nio.file.NoSuchFileException:
> /var/solr/data/blueprint_gnylctsgemcz_users/data/index
> {noformat}
> It seems like the order of directory removal is causing this (first parent
> dir _data_, then sub-dir _data/index_). Entries should be re-arranged or just
> the parent dir be handled.
> Full log with entries dealing with the respective core is attached.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
---------------------------------------------------------------------
To unsubscribe, e-mail: issues-unsubscr...@solr.apache.org
For additional commands, e-mail: issues-h...@solr.apache.org
