[jira] [Commented] (SOLR-16866) CachingDirectoryFactory Throwing Error When Closing
[
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
[jira] [Commented] (SOLR-16866) CachingDirectoryFactory Throwing Error When Closing
[
https://issues.apache.org/jira/browse/SOLR-16866?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17847106#comment-17847106
]
Chris M. Hostetter commented on SOLR-16866:
---
Also, FWIW: I'm not familiar enough with the code paths involved to know if
switching to {{File.separatorChar}} is the right fix (are these Strings
filesystem paths, or "conceptual" paths that have been "normalized" ) but given
the windows test failures i'm going to assume your latest patch is valid.
If no one with a windows box (or better confidence in the code) can validate, i
suggest you commit to main and watch the Windows jenkins builds like a hawk,
and if it starts passing then merge to 9x / 9.6.1
> 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
[jira] [Commented] (SOLR-16866) CachingDirectoryFactory Throwing Error When Closing
[
https://issues.apache.org/jira/browse/SOLR-16866?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17847081#comment-17847081
]
Chris M. Hostetter commented on SOLR-16866:
---
if you have to modify code outside of a test to fix this then it definitely
needs a new Jira since 9.6 is already released.
> 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
[jira] [Commented] (SOLR-16866) CachingDirectoryFactory Throwing Error When Closing
[
https://issues.apache.org/jira/browse/SOLR-16866?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17847048#comment-17847048
]
Houston Putman commented on SOLR-16866:
---
This might actually be a problem on Windows, not just testing, so maybe we
should have a separate Jira for this? So it can be tagged to the 9.6.1 release
> 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
[jira] [Commented] (SOLR-16866) CachingDirectoryFactory Throwing Error When Closing
[
https://issues.apache.org/jira/browse/SOLR-16866?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17847046#comment-17847046
]
Houston Putman commented on SOLR-16866:
---
I think this is due to a bad {{isSubPath()}} method, which used '/' instead of
File.separator. I'll put up a PR, but I can't test this locally since I don't
have a windows machine.
> 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: 3.5h
> 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
[jira] [Commented] (SOLR-16866) CachingDirectoryFactory Throwing Error When Closing
[
https://issues.apache.org/jira/browse/SOLR-16866?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17843281#comment-17843281
]
Chris M. Hostetter commented on SOLR-16866:
---
The {{CachingDirectoryFactoryTest.reorderingTest}} method added by this issue
appears to be failing on many (every?) Windows jenkins build since it was
committed.
A recent main failure...
{noformat}
org.apache.solr.core.CachingDirectoryFactoryTest > reorderingTest FAILED
java.lang.AssertionError
at
__randomizedtesting.SeedInfo.seed([85529424332B55D9:FDFFFBBE80E21597]:0)
at app//org.junit.Assert.fail(Assert.java:87)
at app//org.junit.Assert.assertTrue(Assert.java:42)
at app//org.junit.Assert.assertTrue(Assert.java:53)
at
app//org.apache.solr.core.CachingDirectoryFactoryTest.reorderingTest(CachingDirectoryFactoryTest.java:97)
at
java.base@20.0.2/jdk.internal.reflect.DirectMethodHandleAccessor.invoke(DirectMethodHandleAccessor.java:104)
{noformat}
Line 97...
{code}
assertTrue(pathA.toFile().exists()); // we know there are subdirs that
should prevent removal
{code}
> 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: 3.5h
> 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
[jira] [Commented] (SOLR-16866) CachingDirectoryFactory Throwing Error When Closing
[
https://issues.apache.org/jira/browse/SOLR-16866?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17839123#comment-17839123
]
ASF subversion and git services commented on SOLR-16866:
Commit e07799ea4ef726e533d9181d64ab30844fcac388 in solr's branch
refs/heads/branch_9_6 from Michael Gibney
[ https://gitbox.apache.org/repos/asf?p=solr.git;h=e07799ea4ef ]
SOLR-16866: Reorder nested directory deletions to avoid logging spurious
NoSuchFileException (#2349)
(cherry picked from commit 72793f5b9d9b1c611c8806eb2fa3bf5cc493f651)
> 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
>Priority: Major
> Labels: core
> Attachments: solr.blueprint_gnylctsgemcz_users.log
>
> Time Spent: 3.5h
> 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
[jira] [Commented] (SOLR-16866) CachingDirectoryFactory Throwing Error When Closing
[
https://issues.apache.org/jira/browse/SOLR-16866?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17839122#comment-17839122
]
ASF subversion and git services commented on SOLR-16866:
Commit da6fc5adddc653256050c2ae8870513456c5f00a in solr's branch
refs/heads/branch_9x from Michael Gibney
[ https://gitbox.apache.org/repos/asf?p=solr.git;h=da6fc5adddc ]
SOLR-16866: Reorder nested directory deletions to avoid logging spurious
NoSuchFileException (#2349)
(cherry picked from commit 72793f5b9d9b1c611c8806eb2fa3bf5cc493f651)
> 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
>Priority: Major
> Labels: core
> Attachments: solr.blueprint_gnylctsgemcz_users.log
>
> Time Spent: 3.5h
> 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
[jira] [Commented] (SOLR-16866) CachingDirectoryFactory Throwing Error When Closing
[
https://issues.apache.org/jira/browse/SOLR-16866?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17839120#comment-17839120
]
ASF subversion and git services commented on SOLR-16866:
Commit 72793f5b9d9b1c611c8806eb2fa3bf5cc493f651 in solr's branch
refs/heads/main from Michael Gibney
[ https://gitbox.apache.org/repos/asf?p=solr.git;h=72793f5b9d9 ]
SOLR-16866: Reorder nested directory deletions to avoid logging spurious
NoSuchFileException (#2349)
> 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
>Priority: Major
> Labels: core
> Attachments: solr.blueprint_gnylctsgemcz_users.log
>
> Time Spent: 3.5h
> 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
[jira] [Commented] (SOLR-16866) CachingDirectoryFactory Throwing Error When Closing
[
https://issues.apache.org/jira/browse/SOLR-16866?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17824530#comment-17824530
]
Houston Putman commented on SOLR-16866:
---
I made a PR for this. Was seeing it in the Solr Operator integration tests.
> 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
>Priority: Major
> Labels: core
> Attachments: solr.blueprint_gnylctsgemcz_users.log
>
> Time Spent: 10m
> 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
[jira] [Commented] (SOLR-16866) CachingDirectoryFactory Throwing Error When Closing
[
https://issues.apache.org/jira/browse/SOLR-16866?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17784761#comment-17784761
]
Andreas Hubold commented on SOLR-16866:
---
BTW, FileUtils#deleteDirectory was replaced with PathUtils#deleteDirectory at
quite a number of places. I haven't checked it, but maybe the missing existence
check could cause new exceptions at other places as well.
> 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
>Priority: Major
> Labels: core
> Attachments: solr.blueprint_gnylctsgemcz_users.log
>
>
> 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
[jira] [Commented] (SOLR-16866) CachingDirectoryFactory Throwing Error When Closing
[
https://issues.apache.org/jira/browse/SOLR-16866?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17784757#comment-17784757
]
Andreas Hubold commented on SOLR-16866:
---
This bug did not occur with Solr 8.11.2. It's a regression that was introduced
with SOLR-16074 where
org.apache.solr.core.StandardDirectoryFactory#removeDirectory was changed to
use org.apache.commons.io.file.PathUtils#deleteDirectory(java.nio.file.Path)
instead of org.apache.commons.io.FileUtils#deleteDirectory.
The previously used method from commons-io returns without an error, if the
directory to delete does not exist.
We should add a check in StandardDirectoryFactory#removeDirectory and not call
PathUtils#deleteDirectory for non-existing directories.
> 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
>Priority: Major
> Labels: core
> Attachments: solr.blueprint_gnylctsgemcz_users.log
>
>
> 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
