You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@lucene.apache.org by Michael Sokolov <ms...@gmail.com> on 2020/10/18 15:06:11 UTC
recent test failures in solr.core
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: dev-unsubscribe@lucene.apache.org
For additional commands, e-mail: dev-help@lucene.apache.org
Re: recent test failures in solr.core
Posted by Michael Sokolov <ms...@gmail.com>.
cool, thanks Robert, glad it was easy
On Sun, Oct 18, 2020 at 12:26 PM Robert Muir <rc...@gmail.com> wrote:
>
> 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 <ms...@gmail.com> 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: dev-unsubscribe@lucene.apache.org
>> For additional commands, e-mail: dev-help@lucene.apache.org
>>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@lucene.apache.org
For additional commands, e-mail: dev-help@lucene.apache.org
Re: recent test failures in solr.core
Posted by Robert Muir <rc...@gmail.com>.
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 <ms...@gmail.com> 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: dev-unsubscribe@lucene.apache.org
> For additional commands, e-mail: dev-help@lucene.apache.org
>
>