Mike, thanks for bringing this up.
Looks like it's an easy fix, I will take care. I can't run solr tests on my
machine (they run for hours and always fail), so unfortunately it was
caught by jenkins in this way, sorry.
This change removed the exotic permission that SSD detection needed
(FileStore attributes, the one causing the user NFS-related issues), but it
looks like something else in solr now also relies on it. I'll add it back
for solr with a comment that this IndexFetcher depends on it.
Caused by: java.security.AccessControlException: access denied
("java.lang.RuntimePermission" "getFileStoreAttributes")
at
java.base/java.security.AccessControlContext.checkPermission(AccessControlContext.java:472)
at
java.base/java.security.AccessController.checkPermission(AccessController.java:1036)
at
java.base/java.lang.SecurityManager.checkPermission(SecurityManager.java:408)
at
java.base/sun.nio.fs.UnixFileSystemProvider.getFileStore(UnixFileSystemProvider.java:369)
at java.base/java.nio.file.Files.getFileStore(Files.java:1492)
at
org.apache.solr.handler.IndexFetcher.getUsableSpace(IndexFetcher.java:1046)
On Sun, Oct 18, 2020, 11:06 AM Michael Sokolov <[email protected]> wrote:
> I ran a full test suite this morning and got 51 test failures, all in
> solr.core. It looks like the same has been happening in Jenkins for
> the last couple of days
> https://ci-builds.apache.org/job/Lucene/job/Lucene-Solr-Check-master/.
> Based on timing, the only commit that seemed likely was
>
> LUCENE-9576: nuke SSD detection, modernize CMS defaults
>
> I tried reverting it locally and re-ran solr.core tests and got a pass
> - 0 failures. I don't understand the cause, but there's definitely
> correlation. Is there a bug in the commit? A bad assumption in the
> tests? not sure. Probably we should revert while we sort it out?
>
> -Mike
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [email protected]
> For additional commands, e-mail: [email protected]
>
>
