[
https://issues.apache.org/jira/browse/SOLR-15410?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Colvin Cowie updated SOLR-15410:
--------------------------------
Description:
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 OpenJ9 "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, OpenJ9 changed their handling of -Xlog
options in OpenJ9 0.24.0 (January 2021), so that's presumably the first version
of OpenJ9 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
OpenJ9 ("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 OpenJ9 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
{code:java}
if !JAVA_MAJOR_VERSION! GEQ 9 if NOT "%JAVA_VENDOR%" == "IBM J9" (
{code}
works and would also allow GC_LOG_OPTS to be set in solr.in.cmd for OpenJ9
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 OpenJ9
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}
I've made a similar change to it to make it use -Xverbosegclog on OpenJ9 too.
was:
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}
I've made a similar change to it to make it use -Xverbosegclog on OpenJ9 too.
> 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 OpenJ9 "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, OpenJ9 changed their handling of -Xlog
> options in OpenJ9 0.24.0 (January 2021), so that's presumably the first
> version of OpenJ9 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
> OpenJ9 ("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 OpenJ9 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
> {code:java}
> if !JAVA_MAJOR_VERSION! GEQ 9 if NOT "%JAVA_VENDOR%" == "IBM J9" (
> {code}
> works and would also allow GC_LOG_OPTS to be set in solr.in.cmd for OpenJ9
> 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
> OpenJ9 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}
> I've made a similar change to it to make it use -Xverbosegclog on OpenJ9 too.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
