[
https://issues.apache.org/jira/browse/SOLR-15410?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17346468#comment-17346468
]
Colvin Cowie commented on SOLR-15410:
-------------------------------------
While looking at why it behaves differently on Linux, I've noticed that the
solr.cmd determines that Open J9 is being used in a way that works by chance.
It does this
{code:java}
:resolve_java_vendor
"%JAVA%" -version 2>&1 | findstr /i "IBM J9" > nul
if %ERRORLEVEL% == 1 ( set "JAVA_VENDOR=Oracle" ) else ( set "JAVA_VENDOR=IBM
J9" )
{code}
The doc for findstr states that space is a separator for multiple search terms
if /C: isn't used.
{noformat}
/C:string Uses specified string as a literal search string.
Specifies a file or files to search.Use spaces to separate
multiple search strings unless the argument is prefixed
with /C. For example, 'FINDSTR "hello there" x.y' searches for "hello" or
"there" in file x.y. 'FINDSTR /C:"hello there" x.y' searches for
"hello there" in file x.y.{noformat}
So it's matching on "IBM" or "J9". So the Open J9 output matches J9 only:
{noformat}
Eclipse OpenJ9 VM AdoptOpenJDK (build openj9-0.24.0, JRE 11 Windows 10
amd64-64-Bit Compressed References 20210120_899 (JIT enabled, AOT enabled)
OpenJ9 - 345e1b09e
OMR - 741e94ea8
JCL - 0a86953833 based on jdk-11.0.10+9){noformat}
The solr bash script does the "same" thing, except grep is matching "IBM J9",
so Open J9 is not detected as IBM J9 on linux.
{code:java}
if [ "`echo $JAVA_VER | grep -i "IBM J9"`" != "" ]; then
JAVA_VENDOR="IBM J9"
fi
{code}
> GC log is directed to console when starting Solr with Java 11 Open J9 on
> Windows
> --------------------------------------------------------------------------------
>
> Key: SOLR-15410
> URL: https://issues.apache.org/jira/browse/SOLR-15410
> Project: Solr
> Issue Type: Bug
> Security Level: Public(Default Security Level. Issues are Public)
> Reporter: Colvin Cowie
> Priority: Minor
> Time Spent: 10m
> Remaining Estimate: 0h
>
> This was raised on the mailing list a few months ago:
> [https://lucene.472066.n3.nabble.com/Unrecognized-command-line-option-when-starting-Solr-8-7-with-Java-11-Open-J9-td4470190.html]
>
> Running Solr with OOTB options when using Eclipse Open J9 "11.0.10"+ you get
> an error message stating that the -Xlog:gc option is unrecognised, and the GC
> log is written to the console:
> {noformat}
> "C:\solr\solr-8.6.2\bin\solr.cmd" start -cloud -p 8888 -s
> "C:\solr\solr-8.6.2\example\cloud\node1\solr"
> JVMJ9VM007W Command-line option unrecognised:
> -Xlog:gc*:file="C:\solr\solr-8.6.2\example\cloud\node1\solr\..\logs\solr_gc.log":time,uptime:filecount=9,filesize=20M
> JVMJ9GC063E Unable to open file '"C' for writing
> <?xml version="1.0" ?>
> <verbosegc xmlns="http://www.ibm.com/j9/verbosegc"; version="741e94ea8_CMPRSS">
> <initialized id="1" timestamp="2021-05-17T20:52:49.185">
> <attribute name="gcPolicy" value="-Xgcpolicy:gencon" />
> ...etc...{noformat}
>
> As pointed out on the mailing list, Open J9 changed their handling of -Xlog
> options in OpenJ9 0.24.0 (January 2021), so that's presumably the first
> version of Open J9 affected by this issue.
> The {{-Xlog:gc:<filename>}} syntax is replaced with
> {{-Xverbosegclog:<updated_filename>}} according to
> [https://www.eclipse.org/openj9/docs/xlog/]
> While the bin/solr.cmd has logic for setting {{-Xverbosegclog}} when using
> Open J9 ("IBM J9"), that isn't hit because of this conditional block that was
> added in 2017
> [https://github.com/apache/solr/commit/86f7d6779a8fee56e4497fde7d8936e916b00814#diff-118de7ae5d9fc032e479321cb4d3ee62ceb68e9f3c845292b44c5e14c0f769cfR1116]
> which means that all versions >= 9 get the same
> "GC_LOG_OPTS="-Xlog:gc*:file".
> [~uschindler]'s comment at the time was that ??Java 9 is detected before IBM
> J9. Because IBM J9 for Java 9 will handle the command line options like
> Oracle?? which seems like it was true until Open J9 0.24.0, but no longer
> holds for newer versions.
> I don't know how many people would be using earlier releases of OpenJ9 on
> Windows, but I checked jdk-9.0.4+12_openj9-0.9.0 (August 2018) and
> jdk-11.0.8+10_openj9-0.21.0 (July 2020) and they both started correctly with
> GC logging using the IBM J9 java options already in the solr.cmd file. So
> those options seem to work for OpenJ9 in general. Therefore Lisa's suggestion
> of changing the version check to {{if !JAVA_MAJOR_VERSION! GEQ 9 if NOT
> "%JAVA_VENDOR%" == "IBM J9" (}} works and would also allow GC_LOG_OPTS to be
> set in solr.in.cmd for Open J9 users.
> Otherwise to use the GC_LOG_OPTS hardcoded in the Java 9+ branch of the
> solr.cmd, the {{-XX:+LegacyXlogOption}} could be used to revert -Xlog in Open
> J9 to its previous behaviour, allowing it to parse {{-Xlog:gc}}.
>
> On Linux the bin/solr --the error appears in the solr console log rather than
> the console itself and but the GC log is still created correctly - which is
> strange.
>
> {noformat}
> JVMJ9VM007W Command-line option unrecognised:
> -Xlog:gc*:file=/solr/server/logs/8983/solr_gc.log:time,uptime:filecount=9,filesize=20M{noformat}
>
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
---------------------------------------------------------------------
To unsubscribe, e-mail: issues-unsubscr...@solr.apache.org
For additional commands, e-mail: issues-h...@solr.apache.org
