[
https://issues.apache.org/jira/browse/SOLR-16733?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17756025#comment-17756025
]
Jason Gerlowski commented on SOLR-16733:
----------------------------------------
The commits referenced in the two comments above (^^) work to detect the
JDK20+Mac combination and abort test runs with a (hopefully helpful) message
about the JDK20 issues and pointing them to this ticket.
So between the release note warning added by Houston and this change to our
builds to better flag the broken combination, we might've done about all we can
do here maybe? Is there anything else we should do before closing this ticket
out?
> Solr fails to start on macOS with OpenJDK 20
> --------------------------------------------
>
> Key: SOLR-16733
> URL: https://issues.apache.org/jira/browse/SOLR-16733
> Project: Solr
> Issue Type: Bug
> Components: cli
> Affects Versions: 9.2
> Environment: OS: macOS 13 (Ventura), on x86_64
> (Note: This issue occurred on all combinations of macOS \{11, 12, 13} and
> \{x86_64, arm64}. It is not reproducible on Linux.)
> Java:
> {code:java}
> $ java -version
> openjdk version "20" 2023-03-21
> OpenJDK Runtime Environment (build 20+36-2344)
> OpenJDK 64-Bit Server VM (build 20+36-2344, mixed mode, sharing) {code}
>
>
> Reporter: Ruoyu Zhong
> Priority: Minor
> Attachments: solr-8983-console.log, solr.log, solr_gc.log
>
> Time Spent: 1.5h
> Remaining Estimate: 0h
>
> Solr failed to start on macOS (versions: 11, 12, 13; archs: x86_64, arm64)
> with OpenJDK 20. The following error was observed:
>
> {code:java}
> $ solr-9.2.0/bin/solr start -f
> *** [WARN] *** Your open file limit is currently 256.
> It should be set to 65000 to avoid operational disruption.
> If you no longer wish to see this warning, set SOLR_ULIMIT_CHECKS to false
> in your profile or solr.in.sh
> *** [WARN] *** Your Max Processes Limit is currently 1392.
> It should be set to 65000 to avoid operational disruption.
> If you no longer wish to see this warning, set SOLR_ULIMIT_CHECKS to false
> in your profile or solr.in.sh
> Java 20 detected. Enabled workaround for SOLR-16463
> OpenJDK 64-Bit Server VM warning: -XX:+UseLargePages not supported in this VM
> CompileCommand: exclude
> com/github/benmanes/caffeine/cache/BoundedLocalCache.put bool exclude = true
> WARNING: A command line option has enabled the Security Manager
> WARNING: The Security Manager is deprecated and will be removed in a future
> release
> 2023-04-02 16:19:52.700 WARN (main) [] o.e.j.x.XmlConfiguration Unable to
> execute XmlConfiguration => java.security.AccessControlException: access
> denied ("java.io.FilePermission" "/" "read")
> at
> java.base/java.security.AccessControlContext.checkPermission(AccessControlContext.java:488)
> java.security.AccessControlException: access denied ("java.io.FilePermission"
> "/" "read")
> at
> java.security.AccessControlContext.checkPermission(AccessControlContext.java:488)
> ~[?:?]
> at
> java.security.AccessController.checkPermission(AccessController.java:1071)
> ~[?:?]
> at java.lang.SecurityManager.checkPermission(SecurityManager.java:411)
> ~[?:?]
> at java.lang.SecurityManager.checkRead(SecurityManager.java:742) ~[?:?]
> at sun.nio.fs.UnixPath.checkRead(UnixPath.java:788) ~[?:?]
> at
> sun.nio.fs.UnixFileSystemProvider.newDirectoryStream(UnixFileSystemProvider.java:448)
> ~[?:?]
> at sun.nio.fs.UnixPath.toRealPath(UnixPath.java:912) ~[?:?]
> at
> org.eclipse.jetty.util.resource.PathResource.<init>(PathResource.java:226)
> ~[jetty-util-10.0.13.jar:10.0.13]
> at
> org.eclipse.jetty.util.resource.Resource.newResource(Resource.java:204)
> ~[jetty-util-10.0.13.jar:10.0.13]
> at
> org.eclipse.jetty.util.resource.Resource.newResource(Resource.java:178)
> ~[jetty-util-10.0.13.jar:10.0.13]
> at
> org.eclipse.jetty.xml.XmlConfiguration.lambda$main$4(XmlConfiguration.java:1835)
> ~[jetty-xml-10.0.13.jar:10.0.13]
> at java.security.AccessController.doPrivileged(AccessController.java:571)
> ~[?:?]
> at
> org.eclipse.jetty.xml.XmlConfiguration.main(XmlConfiguration.java:1818)
> ~[jetty-xml-10.0.13.jar:10.0.13]
> at
> jdk.internal.reflect.DirectMethodHandleAccessor.invoke(DirectMethodHandleAccessor.java:104)
> ~[?:?]
> at java.lang.reflect.Method.invoke(Method.java:578) ~[?:?]
> at org.eclipse.jetty.start.Main.invokeMain(Main.java:229)
> ~[start.jar:10.0.13]
> at org.eclipse.jetty.start.Main.start(Main.java:527) ~[start.jar:10.0.13]
> at org.eclipse.jetty.start.Main.main(Main.java:76) ~[start.jar:10.0.13]
> java.lang.reflect.InvocationTargetException
> at
> java.base/jdk.internal.reflect.DirectMethodHandleAccessor.invoke(DirectMethodHandleAccessor.java:119)
> at java.base/java.lang.reflect.Method.invoke(Method.java:578)
> at org.eclipse.jetty.start.Main.invokeMain(Main.java:229)
> at org.eclipse.jetty.start.Main.start(Main.java:527)
> at org.eclipse.jetty.start.Main.main(Main.java:76)
> Caused by: java.security.AccessControlException: access denied
> ("java.io.FilePermission" "/" "read")
> at
> java.base/java.security.AccessControlContext.checkPermission(AccessControlContext.java:488)
> at
> java.base/java.security.AccessController.checkPermission(AccessController.java:1071)
> at
> java.base/java.lang.SecurityManager.checkPermission(SecurityManager.java:411)
> at java.base/java.lang.SecurityManager.checkRead(SecurityManager.java:742)
> at java.base/sun.nio.fs.UnixPath.checkRead(UnixPath.java:788)
> at
> java.base/sun.nio.fs.UnixFileSystemProvider.newDirectoryStream(UnixFileSystemProvider.java:448)
> at java.base/sun.nio.fs.UnixPath.toRealPath(UnixPath.java:912)
> at
> org.eclipse.jetty.util.resource.PathResource.<init>(PathResource.java:226)
> at org.eclipse.jetty.util.resource.Resource.newResource(Resource.java:204)
> at org.eclipse.jetty.util.resource.Resource.newResource(Resource.java:178)
> at
> org.eclipse.jetty.xml.XmlConfiguration.lambda$main$4(XmlConfiguration.java:1835)
> at
> java.base/java.security.AccessController.doPrivileged(AccessController.java:571)
> at org.eclipse.jetty.xml.XmlConfiguration.main(XmlConfiguration.java:1818)
> at
> java.base/jdk.internal.reflect.DirectMethodHandleAccessor.invoke(DirectMethodHandleAccessor.java:104)
> ... 4 more
> java.lang.reflect.InvocationTargetException
> at
> java.base/jdk.internal.reflect.DirectMethodHandleAccessor.invoke(DirectMethodHandleAccessor.java:119)
> at java.base/java.lang.reflect.Method.invoke(Method.java:578)
> at org.eclipse.jetty.start.Main.invokeMain(Main.java:229)
> at org.eclipse.jetty.start.Main.start(Main.java:527)
> at org.eclipse.jetty.start.Main.main(Main.java:76)
> Caused by: java.security.AccessControlException: access denied
> ("java.io.FilePermission" "/" "read")
> at
> java.base/java.security.AccessControlContext.checkPermission(AccessControlContext.java:488)
> at
> java.base/java.security.AccessController.checkPermission(AccessController.java:1071)
> at
> java.base/java.lang.SecurityManager.checkPermission(SecurityManager.java:411)
> at java.base/java.lang.SecurityManager.checkRead(SecurityManager.java:742)
> at java.base/sun.nio.fs.UnixPath.checkRead(UnixPath.java:788)
> at
> java.base/sun.nio.fs.UnixFileSystemProvider.newDirectoryStream(UnixFileSystemProvider.java:448)
> at java.base/sun.nio.fs.UnixPath.toRealPath(UnixPath.java:912)
> at
> org.eclipse.jetty.util.resource.PathResource.<init>(PathResource.java:226)
> at org.eclipse.jetty.util.resource.Resource.newResource(Resource.java:204)
> at org.eclipse.jetty.util.resource.Resource.newResource(Resource.java:178)
> at
> org.eclipse.jetty.xml.XmlConfiguration.lambda$main$4(XmlConfiguration.java:1835)
> at
> java.base/java.security.AccessController.doPrivileged(AccessController.java:571)
> at org.eclipse.jetty.xml.XmlConfiguration.main(XmlConfiguration.java:1818)
> at
> java.base/jdk.internal.reflect.DirectMethodHandleAccessor.invoke(DirectMethodHandleAccessor.java:104)
> ... 4 moreUsage: java -jar $JETTY_HOME/start.jar [options] [properties]
> [configs]
> java -jar $JETTY_HOME/start.jar --help # for more information {code}
>
> Note: the warnings on open file limit and max processes limit do not seem
> related; the error still remains after {{ulimit -n 65000}} and {{{}ulimit -u
> 2088{}}}. {{ulimit -u 2088}} is macOS's hard limit.
> I have attached a full output log ({{{}solr.log{}}}) with {{_JAVA_OPTIONS}}
> set to {{{}-Djava.security.debug=access,failure,policy{}}}. I was running
> that on x86_64 macOS 13.3 (Ventura). (Note:
> [https://github.com/apache/solr/commit/f7fe594cdadeadd1e0061075a55a529793e72462]
> was applied.)
> A minimum reproducer:
> # Download and extract pre-built OpenJDK 20 binaries from
> [https://jdk.java.net/20/] (macOS / AArch64 or macOS / x64).
> # Download and extract Solr 9.2 binary release from
> [https://www.apache.org/dyn/closer.lua/solr/solr/9.2.0/solr-9.2.0.tgz?action=download]
> .
> #
> {code:java}
> export PATH="$PWD/jdk-20.jdk/Contents/Home/bin:$PATH"{code}
> #
> {code:java}
> ./solr-9.2.0/bin/solr start -f{code}
> # See error.
> This failure was observed while packaging OpenJDK 20 for Homebrew at
> [https://github.com/Homebrew/homebrew-core/pull/126319] . At the time of
> testing, Solr 9.1.1 was used. So I believe this error occurred on earlier
> versions, too.
> Thank you! Please let me know if any additional information is needed.
>
--
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
