[jira] [Created] (SOLR-16641) Circular task dependency in gradle
Colvin Cowie created SOLR-16641:
---
Summary: Circular task dependency in gradle
Key: SOLR-16641
URL: https://issues.apache.org/jira/browse/SOLR-16641
Project: Solr
Issue Type: Bug
Security Level: Public (Default Security Level. Issues are Public)
Components: Gradle
Reporter: Colvin Cowie
I sent this to the dev mailing list a few days ago and didn't get a response,
so I'm opening this issue and will create a PR for it.
I just cloned main from
[https://github.com/apache/solr/commit/1135fdfd7c49ff7ef23513ab01b4ee36ffc14f8f]
and to test that everything was working, before I start making changes, I ran
_gradlew tidy updateLicenses check -x test_ just to see that everything would
pass
[https://github.com/apache/solr/blob/main/dev-docs/how-to-contribute.adoc#making-a-new-contribution].
Gradle complains that there's a circular task dependency:
{quote}solr>gradlew tidy updateLicenses check -x test
Downloading gradle-wrapper.jar from
[https://raw.githubusercontent.com/gradle/gradle/v7.6.0/gradle/wrapper/gradle-wrapper.jar]
To honour the JVM settings for this build a single-use Daemon process will be
forked. See
[https://docs.gradle.org/7.6/userguide/gradle_daemon.html#sec:disabling_the_daemon].
Daemon will be stopped at the end of the build
FAILURE: Build failed with an exception.
* What went wrong:
Circular dependency between the following tasks:
:errorProneSkipped
\--- :localSettings
\--- :solr:updateLicenses
+--- :localSettings (*)
+--- :solr:benchmark:collectJarInfos
| +--- :localSettings (*)
| +--- :solr:core:jar
| | +--- :gitStatus
| | | \--- :localSettings (*)
| | +--- :localSettings (*)
| | +--- :solr:core:classes
| | | +--- :localSettings (*)
| | | +--- :solr:core:compileJava
| | | | +--- :errorProneSkipped (*)
| | | | +--- :localSettings (*)
| | | | +--- :solr:core:validateSourcePatterns
| | | | | \--- :localSettings (*)
| | | | +--- :solr:solrj:compileJava
| | | | | +--- :errorProneSkipped (*)
| | | | | +--- :localSettings (*)
| | | | | \--- :solr:solrj:validateSourcePatterns
| | | | | \--- :localSettings (*)
| | | | +--- :solr:solrj-streaming:compileJava
| | | | | +--- :errorProneSkipped (*)
| | | | | +--- :localSettings (*)
| | | | | +--- :solr:solrj:compileJava (*)
| | | | | \---
:solr:solrj-streaming:validateSourcePatterns
| | | | | \--- :localSettings (*)
| | | | \--- :solr:solrj-zookeeper:compileJava
| | | | +--- :errorProneSkipped (*)
| | | | +--- :localSettings (*)
| | | | +--- :solr:solrj:compileJava (*)
| | | | \---
:solr:solrj-zookeeper:validateSourcePatterns
| | | | \--- :localSettings (*)
| | | \--- :solr:core:processResources
| | | \--- :localSettings (*)
| | \--- :solr:core:compileJava (*)
| +--- :solr:solrj:jar
| | +--- :gitStatus (*)
| | +--- :localSettings (*)
| | +--- :solr:solrj:classes
| | | +--- :localSettings (*)
| | | +--- :solr:solrj:compileJava (*)
| | | \--- :solr:solrj:processResources
| | | \--- :localSettings (*)
| | \--- :solr:solrj:compileJava (*)
| +--- :solr:solrj-streaming:jar
| | +--- :gitStatus (*)
| | +--- :localSettings (*)
| | +--- :solr:solrj-streaming:classes
| | | +--- :localSettings (*)
| | | +--- :solr:solrj-streaming:compileJava (*)
| | | \--- :solr:solrj-streaming:processResources
| | | \--- :localSettings (*)
| | \--- :solr:solrj-streaming:compileJava (*)
| +--- :solr:solrj-zookeeper:jar
| | +--- :gitStatus (*)
| | +--- :localSettings (*)
| | +--- :solr:solrj-zookeeper:classes
| | | +--- :localSettings (*)
| | | +--- :solr:solrj-zookeeper:compileJava (*)
| | | \--- :solr:solrj-zookeeper:processResources
| | | \--- :localSettings (*)
| | \--- :solr:solrj-zookeeper:compileJava (*)
| \--- :solr:test
[jira] [Commented] (SOLR-16641) Circular task dependency in gradle
[
https://issues.apache.org/jira/browse/SOLR-16641?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17682465#comment-17682465
]
Colvin Cowie commented on SOLR-16641:
-
I'm happy to just fix it with documentation too. But take a look at
[https://github.com/apache/solr/pull/1320] see whether I'm missing something. I
don't believe that you need a task to do the generation (but I have kept a
skeleton task there for the CI steps to call), it should "just work".
> Circular task dependency in gradle
> --
>
> Key: SOLR-16641
> URL: https://issues.apache.org/jira/browse/SOLR-16641
> Project: Solr
> Issue Type: Bug
> Security Level: Public(Default Security Level. Issues are Public)
> Components: Gradle
>Reporter: Colvin Cowie
>Priority: Trivial
> Time Spent: 10m
> Remaining Estimate: 0h
>
> I sent this to the dev mailing list a few days ago and didn't get a response,
> so I'm opening this issue and will create a PR for it.
>
> I just cloned main from
> [https://github.com/apache/solr/commit/1135fdfd7c49ff7ef23513ab01b4ee36ffc14f8f]
> and to test that everything was working, before I start making changes, I
> ran _gradlew tidy updateLicenses check -x test_ just to see that everything
> would pass
> [https://github.com/apache/solr/blob/main/dev-docs/how-to-contribute.adoc#making-a-new-contribution].
>
> Gradle complains that there's a circular task dependency:
>
> {quote}solr>gradlew tidy updateLicenses check -x test
> Downloading gradle-wrapper.jar from
> [https://raw.githubusercontent.com/gradle/gradle/v7.6.0/gradle/wrapper/gradle-wrapper.jar]
> To honour the JVM settings for this build a single-use Daemon process will be
> forked. See
> [https://docs.gradle.org/7.6/userguide/gradle_daemon.html#sec:disabling_the_daemon].
> Daemon will be stopped at the end of the build
> FAILURE: Build failed with an exception.
> * What went wrong:
> Circular dependency between the following tasks:
> :errorProneSkipped
> \--- :localSettings
> \--- :solr:updateLicenses
> +--- :localSettings (*)
> +--- :solr:benchmark:collectJarInfos
> | +--- :localSettings (*)
> | +--- :solr:core:jar
> | | +--- :gitStatus
> | | | \--- :localSettings (*)
> | | +--- :localSettings (*)
> | | +--- :solr:core:classes
> | | | +--- :localSettings (*)
> | | | +--- :solr:core:compileJava
> | | | | +--- :errorProneSkipped (*)
> | | | | +--- :localSettings (*)
> | | | | +--- :solr:core:validateSourcePatterns
> | | | | | \--- :localSettings (*)
> | | | | +--- :solr:solrj:compileJava
> | | | | | +--- :errorProneSkipped (*)
> | | | | | +--- :localSettings (*)
> | | | | | \--- :solr:solrj:validateSourcePatterns
> | | | | | \--- :localSettings (*)
> | | | | +--- :solr:solrj-streaming:compileJava
> | | | | | +--- :errorProneSkipped (*)
> | | | | | +--- :localSettings (*)
> | | | | | +--- :solr:solrj:compileJava (*)
> | | | | | \---
> :solr:solrj-streaming:validateSourcePatterns
> | | | | | \--- :localSettings (*)
> | | | | \--- :solr:solrj-zookeeper:compileJava
> | | | | +--- :errorProneSkipped (*)
> | | | | +--- :localSettings (*)
> | | | | +--- :solr:solrj:compileJava (*)
> | | | | \---
> :solr:solrj-zookeeper:validateSourcePatterns
> | | | | \--- :localSettings (*)
> | | | \--- :solr:core:processResources
> | | | \--- :localSettings (*)
> | | \--- :solr:core:compileJava (*)
> | +--- :solr:solrj:jar
> | | +--- :gitStatus (*)
> | | +--- :localSettings (*)
> | | +--- :solr:solrj:classes
> | | | +--- :localSettings (*)
> | | | +--- :solr:solrj:compileJava (*)
> | | | \--- :solr:solrj:processResources
> | | | \--- :localSettings (*)
> | | \--- :solr:solrj:compileJava (*)
> | +--- :solr:solrj-streaming:jar
> | | +--- :gitStatus (*)
> | | +--- :localSettings (*)
> | | +--- :solr:solrj-streaming:classes
> | | | +--- :localSettings (*)
> | | | +--- :sol
[jira] [Commented] (SOLR-13396) SolrCloud will delete the core data for any core that is not referenced in the clusterstate
[
https://issues.apache.org/jira/browse/SOLR-13396?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17682548#comment-17682548
]
Colvin Cowie commented on SOLR-13396:
-
I've created a draft PR to add a flag to just disable this behavior,
[https://github.com/apache/solr/pull/1321]. It still needs a test and some
other things, but hopefully it's a starting point for discussion and getting
this fixed in Solr itself.
{quote}[~caomanhdat] added a comment - 04/Oct/19 13:39
Yeah I mean rather than coming up with something complicated. Should we just
improve the logic here so most of the cases will be solved. I.E: check
existence of clusterstate before delete core.
{quote}
I think that even with improvements to the logic, I would still prefer to have
an override that disables automatic deletion of cores. In fact I would prefer
to have to explicitly enable automatic deletion if I want to opt-in to it.
Personally, I think the only time I want a core to be deleted automatically is
if the creation of a new collection/core fails. Otherwise it just makes me very
nervous. I can always clean things up manually, but I can't undelete without a
fresh backup (though obviously regular backups are needed as well but that's
not the point for me).
> SolrCloud will delete the core data for any core that is not referenced in
> the clusterstate
> ---
>
> Key: SOLR-13396
> URL: https://issues.apache.org/jira/browse/SOLR-13396
> Project: Solr
> Issue Type: Bug
> Components: SolrCloud
>Affects Versions: 7.3.1, 8.0
>Reporter: Shawn Heisey
>Priority: Major
> Time Spent: 10m
> Remaining Estimate: 0h
>
> SOLR-12066 is an improvement designed to delete core data for replicas that
> were deleted while the node was down -- better cleanup.
> In practice, that change causes SolrCloud to delete all core data for cores
> that are not referenced in the ZK clusterstate. If all the ZK data gets
> deleted or the Solr instance is pointed at a ZK ensemble with no data, it
> will proceed to delete all of the cores in the solr home, with no possibility
> of recovery.
> I do not think that Solr should ever delete core data unless an explicit
> DELETE action has been made and the node is operational at the time of the
> request. If a core exists during startup that cannot be found in the ZK
> clusterstate, it should be ignored (not started) and a helpful message should
> be logged. I think that message should probably be at WARN so that it shows
> up in the admin UI logging tab with default settings.
--
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
[jira] [Commented] (SOLR-16641) Circular task dependency in gradle
[
https://issues.apache.org/jira/browse/SOLR-16641?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17682588#comment-17682588
]
Colvin Cowie commented on SOLR-16641:
-
{quote}magibney Michael Gibney added a comment - 45 minutes ago
To address the circular dependency directly, it looks like it comes from here.
{quote}
Ah yes! I looked at that, but I dismissed it as validationTasks only collected
tasks named licenses I overlooked the fact it collects the `task.dependsOn`
from those tasks as well.
Filtering out `localSettings` from there fixes it too. So I've put that on the
PR for now, if moving the generation to gradlew isn't worth pursuing.
> Circular task dependency in gradle
> --
>
> Key: SOLR-16641
> URL: https://issues.apache.org/jira/browse/SOLR-16641
> Project: Solr
> Issue Type: Bug
> Security Level: Public(Default Security Level. Issues are Public)
> Components: Gradle
>Reporter: Colvin Cowie
>Priority: Trivial
> Time Spent: 0.5h
> Remaining Estimate: 0h
>
> I sent this to the dev mailing list a few days ago and didn't get a response,
> so I'm opening this issue and will create a PR for it.
>
> I just cloned main from
> [https://github.com/apache/solr/commit/1135fdfd7c49ff7ef23513ab01b4ee36ffc14f8f]
> and to test that everything was working, before I start making changes, I
> ran _gradlew tidy updateLicenses check -x test_ just to see that everything
> would pass
> [https://github.com/apache/solr/blob/main/dev-docs/how-to-contribute.adoc#making-a-new-contribution].
>
> Gradle complains that there's a circular task dependency:
>
> {quote}solr>gradlew tidy updateLicenses check -x test
> Downloading gradle-wrapper.jar from
> [https://raw.githubusercontent.com/gradle/gradle/v7.6.0/gradle/wrapper/gradle-wrapper.jar]
> To honour the JVM settings for this build a single-use Daemon process will be
> forked. See
> [https://docs.gradle.org/7.6/userguide/gradle_daemon.html#sec:disabling_the_daemon].
> Daemon will be stopped at the end of the build
> FAILURE: Build failed with an exception.
> * What went wrong:
> Circular dependency between the following tasks:
> :errorProneSkipped
> \--- :localSettings
> \--- :solr:updateLicenses
> +--- :localSettings (*)
> +--- :solr:benchmark:collectJarInfos
> | +--- :localSettings (*)
> | +--- :solr:core:jar
> | | +--- :gitStatus
> | | | \--- :localSettings (*)
> | | +--- :localSettings (*)
> | | +--- :solr:core:classes
> | | | +--- :localSettings (*)
> | | | +--- :solr:core:compileJava
> | | | | +--- :errorProneSkipped (*)
> | | | | +--- :localSettings (*)
> | | | | +--- :solr:core:validateSourcePatterns
> | | | | | \--- :localSettings (*)
> | | | | +--- :solr:solrj:compileJava
> | | | | | +--- :errorProneSkipped (*)
> | | | | | +--- :localSettings (*)
> | | | | | \--- :solr:solrj:validateSourcePatterns
> | | | | | \--- :localSettings (*)
> | | | | +--- :solr:solrj-streaming:compileJava
> | | | | | +--- :errorProneSkipped (*)
> | | | | | +--- :localSettings (*)
> | | | | | +--- :solr:solrj:compileJava (*)
> | | | | | \---
> :solr:solrj-streaming:validateSourcePatterns
> | | | | | \--- :localSettings (*)
> | | | | \--- :solr:solrj-zookeeper:compileJava
> | | | | +--- :errorProneSkipped (*)
> | | | | +--- :localSettings (*)
> | | | | +--- :solr:solrj:compileJava (*)
> | | | | \---
> :solr:solrj-zookeeper:validateSourcePatterns
> | | | | \--- :localSettings (*)
> | | | \--- :solr:core:processResources
> | | | \--- :localSettings (*)
> | | \--- :solr:core:compileJava (*)
> | +--- :solr:solrj:jar
> | | +--- :gitStatus (*)
> | | +--- :localSettings (*)
> | | +--- :solr:solrj:classes
> | | | +--- :localSettings (*)
> | | | +--- :solr:solrj:compileJava (*)
> | | | \--- :solr:solrj:processResources
> | | | \--- :localSettings (*)
> | | \--- :solr:solrj:compileJava (*)
> | +--- :solr:solrj-streaming:jar
> | | +--- :gitStatus
[jira] [Commented] (SOLR-16641) Circular task dependency in gradle
[
https://issues.apache.org/jira/browse/SOLR-16641?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17682619#comment-17682619
]
Colvin Cowie commented on SOLR-16641:
-
I see [~dweiss] you previously added hooks to the gradlew
[https://github.com/apache/solr/commit/22232a66dd51998bd7f2ecd0fbc6768686d1ecb8#diff-e9721dc750619a21053ddea8a5d04929a608877d8c5daec1b57d243d3424e745R110]
/
[https://github.com/apache/solr/commit/22232a66dd51998bd7f2ecd0fbc6768686d1ecb8#diff-33fbd7a182c496726227993443a3cfea58670618db831c51c273dcd8962c861aR86]
Calling the localSettings task from there would be simple enough, and it would
remove the need for the CI workflows to have it as a separate step. As it will
only run when the file is absent, I don't think it's a bad thing to launch
gradle an extra time there (with --no-daemon)? I don't think it's worth moving
the generation of the properties file out of gradle to do it natively in both.
Here's a rough patch [^0001-SOLR-16641-Generate-from-gradlew.patch] I can put
it in the PR or a separate PR if it's worth doing.
> Circular task dependency in gradle
> --
>
> Key: SOLR-16641
> URL: https://issues.apache.org/jira/browse/SOLR-16641
> Project: Solr
> Issue Type: Bug
> Security Level: Public(Default Security Level. Issues are Public)
> Components: Gradle
>Reporter: Colvin Cowie
>Priority: Trivial
> Attachments: 0001-SOLR-16641-Generate-from-gradlew.patch
>
> Time Spent: 40m
> Remaining Estimate: 0h
>
> I sent this to the dev mailing list a few days ago and didn't get a response,
> so I'm opening this issue and will create a PR for it.
>
> I just cloned main from
> [https://github.com/apache/solr/commit/1135fdfd7c49ff7ef23513ab01b4ee36ffc14f8f]
> and to test that everything was working, before I start making changes, I
> ran _gradlew tidy updateLicenses check -x test_ just to see that everything
> would pass
> [https://github.com/apache/solr/blob/main/dev-docs/how-to-contribute.adoc#making-a-new-contribution].
>
> Gradle complains that there's a circular task dependency:
>
> {quote}solr>gradlew tidy updateLicenses check -x test
> Downloading gradle-wrapper.jar from
> [https://raw.githubusercontent.com/gradle/gradle/v7.6.0/gradle/wrapper/gradle-wrapper.jar]
> To honour the JVM settings for this build a single-use Daemon process will be
> forked. See
> [https://docs.gradle.org/7.6/userguide/gradle_daemon.html#sec:disabling_the_daemon].
> Daemon will be stopped at the end of the build
> FAILURE: Build failed with an exception.
> * What went wrong:
> Circular dependency between the following tasks:
> :errorProneSkipped
> \--- :localSettings
> \--- :solr:updateLicenses
> +--- :localSettings (*)
> +--- :solr:benchmark:collectJarInfos
> | +--- :localSettings (*)
> | +--- :solr:core:jar
> | | +--- :gitStatus
> | | | \--- :localSettings (*)
> | | +--- :localSettings (*)
> | | +--- :solr:core:classes
> | | | +--- :localSettings (*)
> | | | +--- :solr:core:compileJava
> | | | | +--- :errorProneSkipped (*)
> | | | | +--- :localSettings (*)
> | | | | +--- :solr:core:validateSourcePatterns
> | | | | | \--- :localSettings (*)
> | | | | +--- :solr:solrj:compileJava
> | | | | | +--- :errorProneSkipped (*)
> | | | | | +--- :localSettings (*)
> | | | | | \--- :solr:solrj:validateSourcePatterns
> | | | | | \--- :localSettings (*)
> | | | | +--- :solr:solrj-streaming:compileJava
> | | | | | +--- :errorProneSkipped (*)
> | | | | | +--- :localSettings (*)
> | | | | | +--- :solr:solrj:compileJava (*)
> | | | | | \---
> :solr:solrj-streaming:validateSourcePatterns
> | | | | | \--- :localSettings (*)
> | | | | \--- :solr:solrj-zookeeper:compileJava
> | | | | +--- :errorProneSkipped (*)
> | | | | +--- :localSettings (*)
> | | | | +--- :solr:solrj:compileJava (*)
> | | | | \---
> :solr:solrj-zookeeper:validateSourcePatterns
> | | | | \--- :localSettings (*)
> | | | \--- :solr:core:processResources
> | | | \--- :localSettings (*)
> | | \--- :solr:core:compileJava (*)
> | +--- :solr:solrj:jar
> |
[jira] [Updated] (SOLR-16641) Circular task dependency in gradle
[
https://issues.apache.org/jira/browse/SOLR-16641?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Colvin Cowie updated SOLR-16641:
Attachment: 0001-SOLR-16641-Generate-from-gradlew.patch
> Circular task dependency in gradle
> --
>
> Key: SOLR-16641
> URL: https://issues.apache.org/jira/browse/SOLR-16641
> Project: Solr
> Issue Type: Bug
> Security Level: Public(Default Security Level. Issues are Public)
> Components: Gradle
>Reporter: Colvin Cowie
>Priority: Trivial
> Attachments: 0001-SOLR-16641-Generate-from-gradlew.patch
>
> Time Spent: 40m
> Remaining Estimate: 0h
>
> I sent this to the dev mailing list a few days ago and didn't get a response,
> so I'm opening this issue and will create a PR for it.
>
> I just cloned main from
> [https://github.com/apache/solr/commit/1135fdfd7c49ff7ef23513ab01b4ee36ffc14f8f]
> and to test that everything was working, before I start making changes, I
> ran _gradlew tidy updateLicenses check -x test_ just to see that everything
> would pass
> [https://github.com/apache/solr/blob/main/dev-docs/how-to-contribute.adoc#making-a-new-contribution].
>
> Gradle complains that there's a circular task dependency:
>
> {quote}solr>gradlew tidy updateLicenses check -x test
> Downloading gradle-wrapper.jar from
> [https://raw.githubusercontent.com/gradle/gradle/v7.6.0/gradle/wrapper/gradle-wrapper.jar]
> To honour the JVM settings for this build a single-use Daemon process will be
> forked. See
> [https://docs.gradle.org/7.6/userguide/gradle_daemon.html#sec:disabling_the_daemon].
> Daemon will be stopped at the end of the build
> FAILURE: Build failed with an exception.
> * What went wrong:
> Circular dependency between the following tasks:
> :errorProneSkipped
> \--- :localSettings
> \--- :solr:updateLicenses
> +--- :localSettings (*)
> +--- :solr:benchmark:collectJarInfos
> | +--- :localSettings (*)
> | +--- :solr:core:jar
> | | +--- :gitStatus
> | | | \--- :localSettings (*)
> | | +--- :localSettings (*)
> | | +--- :solr:core:classes
> | | | +--- :localSettings (*)
> | | | +--- :solr:core:compileJava
> | | | | +--- :errorProneSkipped (*)
> | | | | +--- :localSettings (*)
> | | | | +--- :solr:core:validateSourcePatterns
> | | | | | \--- :localSettings (*)
> | | | | +--- :solr:solrj:compileJava
> | | | | | +--- :errorProneSkipped (*)
> | | | | | +--- :localSettings (*)
> | | | | | \--- :solr:solrj:validateSourcePatterns
> | | | | | \--- :localSettings (*)
> | | | | +--- :solr:solrj-streaming:compileJava
> | | | | | +--- :errorProneSkipped (*)
> | | | | | +--- :localSettings (*)
> | | | | | +--- :solr:solrj:compileJava (*)
> | | | | | \---
> :solr:solrj-streaming:validateSourcePatterns
> | | | | | \--- :localSettings (*)
> | | | | \--- :solr:solrj-zookeeper:compileJava
> | | | | +--- :errorProneSkipped (*)
> | | | | +--- :localSettings (*)
> | | | | +--- :solr:solrj:compileJava (*)
> | | | | \---
> :solr:solrj-zookeeper:validateSourcePatterns
> | | | | \--- :localSettings (*)
> | | | \--- :solr:core:processResources
> | | | \--- :localSettings (*)
> | | \--- :solr:core:compileJava (*)
> | +--- :solr:solrj:jar
> | | +--- :gitStatus (*)
> | | +--- :localSettings (*)
> | | +--- :solr:solrj:classes
> | | | +--- :localSettings (*)
> | | | +--- :solr:solrj:compileJava (*)
> | | | \--- :solr:solrj:processResources
> | | | \--- :localSettings (*)
> | | \--- :solr:solrj:compileJava (*)
> | +--- :solr:solrj-streaming:jar
> | | +--- :gitStatus (*)
> | | +--- :localSettings (*)
> | | +--- :solr:solrj-streaming:classes
> | | | +--- :localSettings (*)
> | | | +--- :solr:solrj-streaming:compileJava (*)
> | | | \--- :solr:solrj-streaming:processResources
> | | | \--- :localSettings (*)
> | | \--- :solr:solrj-streaming:compileJava (*)
[jira] [Commented] (SOLR-13396) SolrCloud will delete the core data for any core that is not referenced in the clusterstate
[
https://issues.apache.org/jira/browse/SOLR-13396?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17682660#comment-17682660
]
Colvin Cowie commented on SOLR-13396:
-
{quote}It seems the scenario to guard against is the wrong ZK being referenced
(for whatever reason, to include ZK getting wiped clean). In such a scenario
every core on disk will not be linked to a replica in ZK.
{quote}
That does sound fair in general, though I think there's still other scenarios
where that isn't the case.
For example, if I have a test system *A* and a prod system {*}B{*}, and system
*B* has some extra collections in it. I accidentally connect Solr *B* to
ZooKeeper {*}A{*}, which has a subset of {*}A{*}'s collections, then the rest
get wiped. (Granted there's other issues there as I shouldn't really be able to
connect to prod by mistake, but it happens).
Or perhaps if I fail to properly restore a ZooKeeper backup after some sort of
corruption?
{quote}Configuration options to toggle this are okay but it'd be nice to
improve the default behavior because people won't find this configuration
option and use it unless they've been burned :)
{quote}
I definitely agree. My preference would be to default to not automatically
deleting cores, and instead set configuration to enable that. But as that's a
behavior change, I thought I would start with a flag to disable it as being
less contentious.
Making the code itself more sensitive to misconfiguration vs a core that was
left behind by accident would be great as well, but I don't know the code well
enough to address that myself. And I would still be inclined to make the
deletion optional in any case (ideally with an opt-in), so I think there's
value in having a config option with or without improvements to the logic?
> SolrCloud will delete the core data for any core that is not referenced in
> the clusterstate
> ---
>
> Key: SOLR-13396
> URL: https://issues.apache.org/jira/browse/SOLR-13396
> Project: Solr
> Issue Type: Bug
> Components: SolrCloud
>Affects Versions: 7.3.1, 8.0
>Reporter: Shawn Heisey
>Priority: Major
> Time Spent: 10m
> Remaining Estimate: 0h
>
> SOLR-12066 is an improvement designed to delete core data for replicas that
> were deleted while the node was down -- better cleanup.
> In practice, that change causes SolrCloud to delete all core data for cores
> that are not referenced in the ZK clusterstate. If all the ZK data gets
> deleted or the Solr instance is pointed at a ZK ensemble with no data, it
> will proceed to delete all of the cores in the solr home, with no possibility
> of recovery.
> I do not think that Solr should ever delete core data unless an explicit
> DELETE action has been made and the node is operational at the time of the
> request. If a core exists during startup that cannot be found in the ZK
> clusterstate, it should be ignored (not started) and a helpful message should
> be logged. I think that message should probably be at WARN so that it shows
> up in the admin UI logging tab with default settings.
--
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
[jira] [Updated] (SOLR-16641) Circular task dependency in localSettings (Generate gradle.properties from gradlew)
[
https://issues.apache.org/jira/browse/SOLR-16641?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Colvin Cowie updated SOLR-16641:
Summary: Circular task dependency in localSettings (Generate
gradle.properties from gradlew) (was: Circular task dependency in gradle)
> Circular task dependency in localSettings (Generate gradle.properties from
> gradlew)
> ---
>
> Key: SOLR-16641
> URL: https://issues.apache.org/jira/browse/SOLR-16641
> Project: Solr
> Issue Type: Bug
> Security Level: Public(Default Security Level. Issues are Public)
> Components: Gradle
>Reporter: Colvin Cowie
>Priority: Trivial
> Attachments: 0001-SOLR-16641-Generate-from-gradlew.patch
>
> Time Spent: 13h 20m
> Remaining Estimate: 0h
>
> I sent this to the dev mailing list a few days ago and didn't get a response,
> so I'm opening this issue and will create a PR for it.
>
> I just cloned main from
> [https://github.com/apache/solr/commit/1135fdfd7c49ff7ef23513ab01b4ee36ffc14f8f]
> and to test that everything was working, before I start making changes, I
> ran _gradlew tidy updateLicenses check -x test_ just to see that everything
> would pass
> [https://github.com/apache/solr/blob/main/dev-docs/how-to-contribute.adoc#making-a-new-contribution].
>
> Gradle complains that there's a circular task dependency:
>
> {quote}solr>gradlew tidy updateLicenses check -x test
> Downloading gradle-wrapper.jar from
> [https://raw.githubusercontent.com/gradle/gradle/v7.6.0/gradle/wrapper/gradle-wrapper.jar]
> To honour the JVM settings for this build a single-use Daemon process will be
> forked. See
> [https://docs.gradle.org/7.6/userguide/gradle_daemon.html#sec:disabling_the_daemon].
> Daemon will be stopped at the end of the build
> FAILURE: Build failed with an exception.
> * What went wrong:
> Circular dependency between the following tasks:
> :errorProneSkipped
> \--- :localSettings
> \--- :solr:updateLicenses
> +--- :localSettings (*)
> +--- :solr:benchmark:collectJarInfos
> | +--- :localSettings (*)
> | +--- :solr:core:jar
> | | +--- :gitStatus
> | | | \--- :localSettings (*)
> | | +--- :localSettings (*)
> | | +--- :solr:core:classes
> | | | +--- :localSettings (*)
> | | | +--- :solr:core:compileJava
> | | | | +--- :errorProneSkipped (*)
> | | | | +--- :localSettings (*)
> | | | | +--- :solr:core:validateSourcePatterns
> | | | | | \--- :localSettings (*)
> | | | | +--- :solr:solrj:compileJava
> | | | | | +--- :errorProneSkipped (*)
> | | | | | +--- :localSettings (*)
> | | | | | \--- :solr:solrj:validateSourcePatterns
> | | | | | \--- :localSettings (*)
> | | | | +--- :solr:solrj-streaming:compileJava
> | | | | | +--- :errorProneSkipped (*)
> | | | | | +--- :localSettings (*)
> | | | | | +--- :solr:solrj:compileJava (*)
> | | | | | \---
> :solr:solrj-streaming:validateSourcePatterns
> | | | | | \--- :localSettings (*)
> | | | | \--- :solr:solrj-zookeeper:compileJava
> | | | | +--- :errorProneSkipped (*)
> | | | | +--- :localSettings (*)
> | | | | +--- :solr:solrj:compileJava (*)
> | | | | \---
> :solr:solrj-zookeeper:validateSourcePatterns
> | | | | \--- :localSettings (*)
> | | | \--- :solr:core:processResources
> | | | \--- :localSettings (*)
> | | \--- :solr:core:compileJava (*)
> | +--- :solr:solrj:jar
> | | +--- :gitStatus (*)
> | | +--- :localSettings (*)
> | | +--- :solr:solrj:classes
> | | | +--- :localSettings (*)
> | | | +--- :solr:solrj:compileJava (*)
> | | | \--- :solr:solrj:processResources
> | | | \--- :localSettings (*)
> | | \--- :solr:solrj:compileJava (*)
> | +--- :solr:solrj-streaming:jar
> | | +--- :gitStatus (*)
> | | +--- :localSettings (*)
> | | +--- :solr:solrj-streaming:classes
> | | | +--- :localSettings (*)
> | | | +--- :solr:solrj-streaming:compileJava (*)
>
[jira] [Created] (SOLR-16645) Support ss and netstat as alternatives to lsof
Colvin Cowie created SOLR-16645:
---
Summary: Support ss and netstat as alternatives to lsof
Key: SOLR-16645
URL: https://issues.apache.org/jira/browse/SOLR-16645
Project: Solr
Issue Type: Improvement
Security Level: Public (Default Security Level. Issues are Public)
Reporter: Colvin Cowie
The current start command requires {{lsof}} to be available. If you don't have
{{lsof}} it does a hardcoded 10 second wait and then assumes the process has
started.
There are several other tools common tools that can be used if lsof` isn't
available, so I'll create a PR to add netstat and ss as alternative options.
--
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
[jira] [Created] (SOLR-16647) Circuit breakers example is wrong in _default solrconfig.xml
Colvin Cowie created SOLR-16647: --- Summary: Circuit breakers example is wrong in _default solrconfig.xml Key: SOLR-16647 URL: https://issues.apache.org/jira/browse/SOLR-16647 Project: Solr Issue Type: Improvement Security Level: Public (Default Security Level. Issues are Public) Reporter: Colvin Cowie Attachments: image-2023-02-04-12-08-26-407.png I was diffing the solrconfig.xml in _default and sample_techproducts_configs and saw that they had different circuitBreaker config. The one in _default uses invalid tags according to [https://solr.apache.org/guide/solr/latest/deployment-guide/circuit-breakers.html#circuit-breaker-configurations] The default config attempts to enable circuit breakers, but I don't think they actually are enabled given the apparently invalid XML tags [https://github.com/apache/solr/blob/92b376a17482496a197ce9c20b5b757f9b354724/solr/server/solr/configsets/_default/conf/solrconfig.xml#L578] The sample techproducts config has them commented out, but uses the correct tags [https://github.com/apache/solr/blob/c96c78132d77974adaec62ffaaf4b819f76f49a9/solr/server/solr/configsets/sample_techproducts_configs/conf/solrconfig.xml#L600] !image-2023-02-04-12-08-26-407.png! -- 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
[jira] [Updated] (SOLR-16647) Circuit breaker examples are wrong and don't match documentation
[ https://issues.apache.org/jira/browse/SOLR-16647?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Colvin Cowie updated SOLR-16647: Summary: Circuit breaker examples are wrong and don't match documentation (was: Circuit breakers example is wrong in _default solrconfig.xml) > Circuit breaker examples are wrong and don't match documentation > > > Key: SOLR-16647 > URL: https://issues.apache.org/jira/browse/SOLR-16647 > Project: Solr > Issue Type: Improvement > Security Level: Public(Default Security Level. Issues are Public) >Reporter: Colvin Cowie >Priority: Trivial > Attachments: image-2023-02-04-12-08-26-407.png > > > I was diffing the solrconfig.xml in _default and sample_techproducts_configs > and saw that they had different circuitBreaker config. The one in _default > uses invalid tags according to > [https://solr.apache.org/guide/solr/latest/deployment-guide/circuit-breakers.html#circuit-breaker-configurations] > The default config attempts to enable circuit breakers, but I don't think > they actually are enabled given the apparently invalid XML tags > [https://github.com/apache/solr/blob/92b376a17482496a197ce9c20b5b757f9b354724/solr/server/solr/configsets/_default/conf/solrconfig.xml#L578] > > The sample techproducts config has them commented out, but uses the correct > tags > [https://github.com/apache/solr/blob/c96c78132d77974adaec62ffaaf4b819f76f49a9/solr/server/solr/configsets/sample_techproducts_configs/conf/solrconfig.xml#L600] > > !image-2023-02-04-12-08-26-407.png! -- 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
[jira] [Updated] (SOLR-16647) Circuit breaker examples are wrong and don't match documentation
[
https://issues.apache.org/jira/browse/SOLR-16647?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Colvin Cowie updated SOLR-16647:
Description:
I was diffing the solrconfig.xml in _default and sample_techproducts_configs
and saw that they had different circuitBreaker config. The one in _default uses
invalid tags according to
[https://solr.apache.org/guide/solr/latest/deployment-guide/circuit-breakers.html#circuit-breaker-configurations]
The default config attempts to enable circuit breakers, but I don't think they
actually are enabled given the apparently invalid XML tags
[https://github.com/apache/solr/blob/92b376a17482496a197ce9c20b5b757f9b354724/solr/server/solr/configsets/_default/conf/solrconfig.xml#L578]
The sample techproducts config has them commented out, but uses the correct tags
[https://github.com/apache/solr/blob/c96c78132d77974adaec62ffaaf4b819f76f49a9/solr/server/solr/configsets/sample_techproducts_configs/conf/solrconfig.xml#L600]
!image-2023-02-04-12-08-26-407.png!
Also the documentation says to configure the breakers like this:
{code:java}
true
75
true
75{code}
But the example configs use
{code:java}
100
{code}
Looks like documentation is correct and the examples are wrong:
[https://github.com/apache/solr/blob/c99af207c761ec34812ef1cc3054eb2804b7448b/solr/core/src/java/org/apache/solr/util/circuitbreaker/CircuitBreakerManager.java#L160:L163]
was:
I was diffing the solrconfig.xml in _default and sample_techproducts_configs
and saw that they had different circuitBreaker config. The one in _default uses
invalid tags according to
[https://solr.apache.org/guide/solr/latest/deployment-guide/circuit-breakers.html#circuit-breaker-configurations]
The default config attempts to enable circuit breakers, but I don't think they
actually are enabled given the apparently invalid XML tags
[https://github.com/apache/solr/blob/92b376a17482496a197ce9c20b5b757f9b354724/solr/server/solr/configsets/_default/conf/solrconfig.xml#L578]
The sample techproducts config has them commented out, but uses the correct tags
[https://github.com/apache/solr/blob/c96c78132d77974adaec62ffaaf4b819f76f49a9/solr/server/solr/configsets/sample_techproducts_configs/conf/solrconfig.xml#L600]
!image-2023-02-04-12-08-26-407.png!
> Circuit breaker examples are wrong and don't match documentation
>
>
> Key: SOLR-16647
> URL: https://issues.apache.org/jira/browse/SOLR-16647
> Project: Solr
> Issue Type: Improvement
> Security Level: Public(Default Security Level. Issues are Public)
>Reporter: Colvin Cowie
>Priority: Trivial
> Attachments: image-2023-02-04-12-08-26-407.png
>
>
> I was diffing the solrconfig.xml in _default and sample_techproducts_configs
> and saw that they had different circuitBreaker config. The one in _default
> uses invalid tags according to
> [https://solr.apache.org/guide/solr/latest/deployment-guide/circuit-breakers.html#circuit-breaker-configurations]
> The default config attempts to enable circuit breakers, but I don't think
> they actually are enabled given the apparently invalid XML tags
> [https://github.com/apache/solr/blob/92b376a17482496a197ce9c20b5b757f9b354724/solr/server/solr/configsets/_default/conf/solrconfig.xml#L578]
>
> The sample techproducts config has them commented out, but uses the correct
> tags
> [https://github.com/apache/solr/blob/c96c78132d77974adaec62ffaaf4b819f76f49a9/solr/server/solr/configsets/sample_techproducts_configs/conf/solrconfig.xml#L600]
>
> !image-2023-02-04-12-08-26-407.png!
>
> Also the documentation says to configure the breakers like this:
> {code:java}
> true
> 75
> true
> 75{code}
> But the example configs use
> {code:java}
> 100
> {code}
> Looks like documentation is correct and the examples are wrong:
> [https://github.com/apache/solr/blob/c99af207c761ec34812ef1cc3054eb2804b7448b/solr/core/src/java/org/apache/solr/util/circuitbreaker/CircuitBreakerManager.java#L160:L163]
>
>
--
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
[jira] [Commented] (SOLR-16619) `solr status` and `solr create` do not work on IBM i
[
https://issues.apache.org/jira/browse/SOLR-16619?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17689758#comment-17689758
]
Colvin Cowie commented on SOLR-16619:
-
I could take a look more closely next week, I've just had a look at how ps is
used currently. in main there's ~20 uses of ps, with several variations of
arguments. It might be worth refactoring most of the existing usages to use a
common function or two to DRY it out, because it's quite hard to understand
what the intention of each one is and whether they all need different slightly
arguments or not.
Here's a summary of the uses I saw:
# This one is used twice and counts the number of Solr PIDs running:
** {{numSolrs=$(ps auxww | grep start\.jar | grep solr\.solr\.home | grep -v
grep | wc -l | sed -e 's/^[ \t]*//')}}
**
[https://github.com/apache/solr/blob/f804af73397c6e4c1f14254af218714da751d047/solr/bin/solr#L770]
**
[https://github.com/apache/solr/blob/f804af73397c6e4c1f14254af218714da751d047/solr/bin/solr#L817]
# This one is used once within the above to get the PIDs rather than the
count...
** {{PROCESSES=$(ps auxww | grep start\.jar | grep solr\.solr\.home | grep -v
grep | awk '\{print $2}' | sort -r)}}
**
[https://github.com/apache/solr/blob/f804af73397c6e4c1f14254af218714da751d047/solr/bin/solr#L820]
# Used 3 times with jetty_port() to "extract the value of the -Djetty.port
parameter from a running Solr process":
** {{for ID in $(ps auxww | grep java | grep start\.jar | awk '\{print $2}' |
sort -r)}}
**
[https://github.com/apache/solr/blob/f804af73397c6e4c1f14254af218714da751d047/solr/bin/solr#L1169]
**
[https://github.com/apache/solr/blob/f804af73397c6e4c1f14254af218714da751d047/solr/bin/solr#L1276]
**
[https://github.com/apache/solr/blob/f804af73397c6e4c1f14254af218714da751d047/solr/bin/solr#L1579]
# Used 4 times to determine the PID:
** {{SOLR_PID=$(ps auxww | grep start\.jar | awk
"/\-Djetty\.port=$SOLR_PORT/"' \{print $2}' | sort -r)}}
**
[https://github.com/apache/solr/blob/f804af73397c6e4c1f14254af218714da751d047/solr/bin/solr#L1935]
**
[https://github.com/apache/solr/blob/f804af73397c6e4c1f14254af218714da751d047/solr/bin/solr#L1948]
**
[https://github.com/apache/solr/blob/f804af73397c6e4c1f14254af218714da751d047/solr/bin/solr#L2339]
**
[https://github.com/apache/solr/blob/f804af73397c6e4c1f14254af218714da751d047/solr/bin/solr#L2348]
# Used in the jetty_port() function to extract the command line args that
started it:
** {{SOLR_PROC=$(ps -o command='' -p "$SOLR_PID" | grep start\.jar | grep
jetty\.port)}}
**
[https://github.com/apache/solr/blob/f804af73397c6e4c1f14254af218714da751d047/solr/bin/solr#L721]
# Check whether the PID is still alive while shutting down
** {{while ps -o pid='' -p "$pid" &> /dev/null ; do}}
**
[https://github.com/apache/solr/blob/f804af73397c6e4c1f14254af218714da751d047/solr/bin/solr#L696]
# Used twice (same command as above really):
** {{CHECK_PID=$(ps -o pid='' -p "$PID" | tr -d ' ')}}
**
[https://github.com/apache/solr/blob/f804af73397c6e4c1f14254af218714da751d047/solr/bin/solr#L711]
**
[https://github.com/apache/solr/blob/f804af73397c6e4c1f14254af218714da751d047/solr/bin/solr#L1887]
# Used 3 times when stopping, the stat is important here for checking for
Zombie processes.
** {{STAT=$( (ps -o stat='' -p "$SOLR_PID" || :) | tr -d ' ')}}
**
[https://github.com/apache/solr/blob/f804af73397c6e4c1f14254af218714da751d047/solr/bin/solr#L866]
**
[https://github.com/apache/solr/blob/f804af73397c6e4c1f14254af218714da751d047/solr/bin/solr#L887]
**
[https://github.com/apache/solr/blob/f804af73397c6e4c1f14254af218714da751d047/solr/bin/solr#L904]
If I've interpreted them all correctly:
# Counts the number of Solr processes
# Gets the PIDs of all Solr processes
# Gets the PIDs of all Jetty processes
# Gets the PID for an instance of jetty started with a specific port
# Gets the command line arguments for a known PID if it's a jetty instance
# Check PID is alive
# Check PID is alive
# Check if PID is alive and not a Zombie
Then
* 1 could be determined from 2 rather than repeating the ps
* 2 and 3 are essentially doing the same things, so could have a single
function
* 6 and 7 and 8 could use a single function that returns the STAT for a PID if
it's running.
* 4 could be replaced with lsof, which is used to determine the PID from a
port during stop commands (or they could use ps instead)
** (Also I have a [PR|https://github.com/apache/solr/pull/1328] to add support
for ss and netstat as alternatives when lsof isn't available, but need to sort
out mac support for some of the arguments...)
* 5 exists to determine a port from a PID, so unless there's something special
about the logic for that which needs to be preserved, it could also be done
with lsof.
> `solr status` and `solr create` do not work on IBM i
> -
[jira] [Commented] (SOLR-16619) `solr status` and `solr create` do not work on IBM i
[ https://issues.apache.org/jira/browse/SOLR-16619?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17689760#comment-17689760 ] Colvin Cowie commented on SOLR-16619: - Ahh, Jira ruined my formatting. Hopefully it makes sense enough sense without me trying to edit it... :) > `solr status` and `solr create` do not work on IBM i > > > Key: SOLR-16619 > URL: https://issues.apache.org/jira/browse/SOLR-16619 > Project: Solr > Issue Type: Bug >Affects Versions: 8.11.2, 9.1 > Environment: Pase on IBM i using Java 11 with OpenJDK >Reporter: Jesse Gorzinski >Priority: Minor > Time Spent: 0.5h > Remaining Estimate: 0h > > The `solr status` and `solr create` commands fail on the IBM i platform. > For example > ``` > Solr process 3391 from /solr/solr-8.11.2/bin/solr-8983.pid not found > ``` -- 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
[jira] [Created] (SOLR-17099) Unsolicited snitch tag warnings from AttributeFetcherImpl
Colvin Cowie created SOLR-17099: --- Summary: Unsolicited snitch tag warnings from AttributeFetcherImpl Key: SOLR-17099 URL: https://issues.apache.org/jira/browse/SOLR-17099 Project: Solr Issue Type: Bug Security Level: Public (Default Security Level. Issues are Public) Affects Versions: 9.4, 9.3 Reporter: Colvin Cowie I first spotted this in 9.3, I've not gone back to check earlier versions, though it is likely to affect them too. When configuring replica placement rules on a standard out of the box deployment and creating a collection, error messages are logged like this: 2023-09-27 08:45:58.188 ERROR (OverseerThreadFactory-19-thread-5) [] o.a.s.c.p.i.AttributeFetcherImpl Received unsolicited snitch tag heapUsage from node NodeImpl(localhost:8983_solr) 2023-09-27 08:45:58.188 ERROR (OverseerThreadFactory-19-thread-5) [] o.a.s.c.p.i.AttributeFetcherImpl Received unsolicited snitch tag sysLoadAvg from node NodeImpl(localhost:8983_solr) 2023-09-27 08:45:58.188 ERROR (OverseerThreadFactory-19-thread-5) [] o.a.s.c.p.i.AttributeFetcherImpl Received unsolicited snitch tag freedisk from node NodeImpl(localhost:8983_solr) 2023-09-27 08:45:58.188 ERROR (OverseerThreadFactory-19-thread-5) [] o.a.s.c.p.i.AttributeFetcherImpl Received unsolicited snitch tag totaldisk from node NodeImpl(localhost:8983_solr) That error comes from here: [https://github.com/apache/lucene-solr/commit/c7d234cafd37d824ff6642b449d3cb333d1e4a9a#r129141901] [~ilan] said "I suspect it was introduced with SOLR-15019 ([commit|https://github.com/apache/lucene-solr/blob/2695624a9f2d11a63f3640dd7f3bb30c2e6f938e/solr/core/src/java/org/apache/solr/cluster/placement/impl/AttributeFetcherImpl.java#L69]) when requested tags were prefixed with sysprop. but returned tags apparently not." The error is fairly benign, it just pollutes the logs and makes it look like something is wrong but everything else functions correctly (if you aren't trying to configure rules based on those four metrics at least). -- 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
[jira] [Created] (SOLR-17168) Netty epoll implementation not included in 8.11.3
Colvin Cowie created SOLR-17168:
---
Summary: Netty epoll implementation not included in 8.11.3
Key: SOLR-17168
URL: https://issues.apache.org/jira/browse/SOLR-17168
Project: Solr
Issue Type: Bug
Security Level: Public (Default Security Level. Issues are Public)
Affects Versions: 8.11.3
Reporter: Colvin Cowie
Solr 8.11.3 updated netty from 4.1.69 to 4.1.99.
While it still contains the [netty-transport-native-epoll
dependency,|https://github.com/apache/lucene-solr/blob/9ebfd2b0a584faa072685fff4956f05b52e60d7c/lucene/ivy-versions.properties#L120-L129]
the epoll implementation moved to a [separate
jar|https://mvnrepository.com/artifact/io.netty/netty-transport-classes-epoll]
in netty 4.1.70.
That jar is included in Solr 9, but it's not been added to the ivy-versions
used in Solr 8.
As a result, attemping to use Netty for SSL results in an exception:
{quote}{{2024-02-20T09:53:17.350:out: Caused by:
java.lang.NoClassDefFoundError: io/netty/channel/epoll/Epoll
2024-02-20T09:53:17.352:out: at
org.apache.zookeeper.common.NettyUtils.newNioOrEpollEventLoopGroup(NettyUtils.java:74)
~[zookeeper-3.6.2.jar:3.6.2]
2024-02-20T09:53:17.353:out: at
org.apache.zookeeper.ClientCnxnSocketNetty.(ClientCnxnSocketNetty.java:86)
~[zookeeper-3.6.2.jar:3.6.2]
2024-02-20T09:53:17.355:out: at
jdk.internal.reflect.NativeConstructorAccessorImpl.newInstance0(Native Method)
~[?:?]
2024-02-20T09:53:17.357:out: at
jdk.internal.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:62)
~[?:?]
2024-02-20T09:53:17.358:out: at
jdk.internal.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:45)
~[?:?]
2024-02-20T09:53:17.360:out: at
java.lang.reflect.Constructor.newInstance(Constructor.java:490) ~[?:?]
2024-02-20T09:53:17.361:out: at
org.apache.zookeeper.ZooKeeper.getClientCnxnSocket(ZooKeeper.java:3404)
~[zookeeper-3.6.2.jar:3.6.2]
2024-02-20T09:53:17.363:out: at
org.apache.zookeeper.ZooKeeper.(ZooKeeper.java:1027)
~[zookeeper-3.6.2.jar:3.6.2]
2024-02-20T09:53:17.364:out: at
org.apache.zookeeper.ZooKeeper.(ZooKeeper.java:937)
~[zookeeper-3.6.2.jar:3.6.2]
2024-02-20T09:53:17.366:out: at
org.apache.zookeeper.ZooKeeper.(ZooKeeper.java:1108)
~[zookeeper-3.6.2.jar:3.6.2]
2024-02-20T09:53:17.368:out: at
org.apache.zookeeper.ZooKeeper.(ZooKeeper.java:818)
~[zookeeper-3.6.2.jar:3.6.2]
2024-02-20T09:53:17.369:out: at
org.apache.solr.common.cloud.SolrZooKeeper.(SolrZooKeeper.java:44)
~[solr-solrj-8.11.3.jar:8.11.3 baa7c80af4278cc8951a344d8e9320386588d12d -
houstonputman - 2024-02-05 15:08:47]
2024-02-20T09:53:17.371:out: at
org.apache.solr.common.cloud.ZkClientConnectionStrategy.createSolrZooKeeper(ZkClientConnectionStrategy.java:109)
~[solr-solrj-8.11.3.jar:8.11.3 baa7c80af4278cc8951a344d8e9320386588d12d -
houstonputman - 2024-02-05 15:08:47]
2024-02-20T09:53:17.372:out: at
org.apache.solr.common.cloud.DefaultConnectionStrategy.connect(DefaultConnectionStrategy.java:37)
~[solr-solrj-8.11.3.jar:8.11.3 baa7c80af4278cc8951a344d8e9320386588d12d -
houstonputman - 2024-02-05 15:08:47]
2024-02-20T09:53:17.374:out: at
org.apache.solr.common.cloud.SolrZkClient.(SolrZkClient.java:166)
~[solr-solrj-8.11.3.jar:8.11.3 baa7c80af4278cc8951a344d8e9320386588d12d -
houstonputman - 2024-02-05 15:08:47]
2024-02-20T09:53:17.375:out: ... 7 more
2024-02-20T09:53:17.377:out: Caused by: java.lang.ClassNotFoundException:
io.netty.channel.epoll.Epoll
2024-02-20T09:53:17.379:out: at
jdk.internal.loader.BuiltinClassLoader.loadClass(BuiltinClassLoader.java:581)
~[?:?]
2024-02-20T09:53:17.381:out: at
jdk.internal.loader.ClassLoaders$AppClassLoader.loadClass(ClassLoaders.java:178)
~[?:?]
2024-02-20T09:53:17.382:out: at
java.lang.ClassLoader.loadClass(ClassLoader.java:527) ~[?:?]
2024-02-20T09:53:17.384:out: at
org.apache.zookeeper.common.NettyUtils.newNioOrEpollEventLoopGroup(NettyUtils.java:74)
~[zookeeper-3.6.2.jar:3.6.2]
2024-02-20T09:53:17.386:out: at
org.apache.zookeeper.ClientCnxnSocketNetty.(ClientCnxnSocketNetty.java:86)
~[zookeeper-3.6.2.jar:3.6.2]
2024-02-20T09:53:17.387:out: at
jdk.internal.reflect.NativeConstructorAccessorImpl.newInstance0(Native Method)
~[?:?]
2024-02-20T09:53:17.389:out: at
jdk.internal.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:62)
~[?:?]
2024-02-20T09:53:17.391:out: at
jdk.internal.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:45)
~[?:?]
2024-02-20T09:53:17.392:out: at
java.lang.reflect.Constructor.newInstance(Constructor.java:490) ~[?:?]
2024-02-20T09:53:17.394:out: at
org.apache.zookeeper.ZooKeeper.getClientCnxnSocket(ZooKeeper.java:3404)
~[zookeeper-3.6.2.jar:3.6.2]
2024-02-20T09:53:17.396:out: at
org.apache.zookeeper.ZooKeeper.(ZooKeeper.java:1027)
~[zookeeper-3.6.2.jar:3.6.2]
2024-02-20T09:53:17.397:out
[jira] [Commented] (SOLR-17168) Netty epoll implementation not included in 8.11.3
[
https://issues.apache.org/jira/browse/SOLR-17168?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17818832#comment-17818832
]
Colvin Cowie commented on SOLR-17168:
-
[https://github.com/apache/lucene-solr/pull/2684] - I've not updated
dependencies on the ant build before, so I did what I thought was needed for
updating the license/notices based on previous commits.
> Netty epoll implementation not included in 8.11.3
> -
>
> Key: SOLR-17168
> URL: https://issues.apache.org/jira/browse/SOLR-17168
> Project: Solr
> Issue Type: Bug
> Security Level: Public(Default Security Level. Issues are Public)
>Affects Versions: 8.11.3
>Reporter: Colvin Cowie
>Priority: Minor
> Time Spent: 10m
> Remaining Estimate: 0h
>
> Solr 8.11.3 updated netty from 4.1.69 to 4.1.99.
> While it still contains the [netty-transport-native-epoll
> dependency,|https://github.com/apache/lucene-solr/blob/9ebfd2b0a584faa072685fff4956f05b52e60d7c/lucene/ivy-versions.properties#L120-L129]
> the epoll implementation moved to a [separate
> jar|https://mvnrepository.com/artifact/io.netty/netty-transport-classes-epoll]
> in netty 4.1.70.
> That jar is included in Solr 9, but it's not been added to the ivy-versions
> used in Solr 8.
> As a result, attemping to use Netty for SSL results in an exception:
> {quote}{{2024-02-20T09:53:17.350:out: Caused by:
> java.lang.NoClassDefFoundError: io/netty/channel/epoll/Epoll
> 2024-02-20T09:53:17.352:out: at
> org.apache.zookeeper.common.NettyUtils.newNioOrEpollEventLoopGroup(NettyUtils.java:74)
> ~[zookeeper-3.6.2.jar:3.6.2]
> 2024-02-20T09:53:17.353:out: at
> org.apache.zookeeper.ClientCnxnSocketNetty.(ClientCnxnSocketNetty.java:86)
> ~[zookeeper-3.6.2.jar:3.6.2]
> 2024-02-20T09:53:17.355:out: at
> jdk.internal.reflect.NativeConstructorAccessorImpl.newInstance0(Native
> Method) ~[?:?]
> 2024-02-20T09:53:17.357:out: at
> jdk.internal.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:62)
> ~[?:?]
> 2024-02-20T09:53:17.358:out: at
> jdk.internal.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:45)
> ~[?:?]
> 2024-02-20T09:53:17.360:out: at
> java.lang.reflect.Constructor.newInstance(Constructor.java:490) ~[?:?]
> 2024-02-20T09:53:17.361:out: at
> org.apache.zookeeper.ZooKeeper.getClientCnxnSocket(ZooKeeper.java:3404)
> ~[zookeeper-3.6.2.jar:3.6.2]
> 2024-02-20T09:53:17.363:out: at
> org.apache.zookeeper.ZooKeeper.(ZooKeeper.java:1027)
> ~[zookeeper-3.6.2.jar:3.6.2]
> 2024-02-20T09:53:17.364:out: at
> org.apache.zookeeper.ZooKeeper.(ZooKeeper.java:937)
> ~[zookeeper-3.6.2.jar:3.6.2]
> 2024-02-20T09:53:17.366:out: at
> org.apache.zookeeper.ZooKeeper.(ZooKeeper.java:1108)
> ~[zookeeper-3.6.2.jar:3.6.2]
> 2024-02-20T09:53:17.368:out: at
> org.apache.zookeeper.ZooKeeper.(ZooKeeper.java:818)
> ~[zookeeper-3.6.2.jar:3.6.2]
> 2024-02-20T09:53:17.369:out: at
> org.apache.solr.common.cloud.SolrZooKeeper.(SolrZooKeeper.java:44)
> ~[solr-solrj-8.11.3.jar:8.11.3 baa7c80af4278cc8951a344d8e9320386588d12d -
> houstonputman - 2024-02-05 15:08:47]
> 2024-02-20T09:53:17.371:out: at
> org.apache.solr.common.cloud.ZkClientConnectionStrategy.createSolrZooKeeper(ZkClientConnectionStrategy.java:109)
> ~[solr-solrj-8.11.3.jar:8.11.3 baa7c80af4278cc8951a344d8e9320386588d12d -
> houstonputman - 2024-02-05 15:08:47]
> 2024-02-20T09:53:17.372:out: at
> org.apache.solr.common.cloud.DefaultConnectionStrategy.connect(DefaultConnectionStrategy.java:37)
> ~[solr-solrj-8.11.3.jar:8.11.3 baa7c80af4278cc8951a344d8e9320386588d12d -
> houstonputman - 2024-02-05 15:08:47]
> 2024-02-20T09:53:17.374:out: at
> org.apache.solr.common.cloud.SolrZkClient.(SolrZkClient.java:166)
> ~[solr-solrj-8.11.3.jar:8.11.3 baa7c80af4278cc8951a344d8e9320386588d12d -
> houstonputman - 2024-02-05 15:08:47]
> 2024-02-20T09:53:17.375:out: ... 7 more
> 2024-02-20T09:53:17.377:out: Caused by: java.lang.ClassNotFoundException:
> io.netty.channel.epoll.Epoll
> 2024-02-20T09:53:17.379:out: at
> jdk.internal.loader.BuiltinClassLoader.loadClass(BuiltinClassLoader.java:581)
> ~[?:?]
> 2024-02-20T09:53:17.381:out: at
> jdk.internal.loader.ClassLoaders$AppClassLoader.loadClass(ClassLoaders.java:178)
> ~[?:?]
> 2024-02-20T09:53:17.382:out: at
> java.lang.ClassLoader.loadClass(ClassLoader.java:527) ~[?:?]
> 2024-02-20T09:53:17.384:out: at
> org.apache.zookeeper.common.NettyUtils.newNioOrEpollEventLoopGroup(NettyUtils.java:74)
> ~[zookeeper-3.6.2.jar:3.6.2]
> 2024-02-20T09:53:17.386:out: at
> org.apache.zookeeper.ClientCnxnSocketNetty.(ClientCnxnSocketNetty.java:86)
> ~[zookeeper-3.6.2.jar:3.6.2]
> 2024-02-20T09:53:17.387:out: at
> jdk.internal.reflect.NativeConstructorAccessorImpl.newInstance0(Native
> Method) ~[?:?]
> 2024-02-
[jira] [Resolved] (SOLR-15464) Solr 9.0 will not start using OpenJ9
[
https://issues.apache.org/jira/browse/SOLR-15464?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Colvin Cowie resolved SOLR-15464.
-
Resolution: Won't Do
Based on [https://www.mail-archive.com/dev@lucene.apache.org/msg315523.html]
and [https://jenkins.thetaphi.de/job/Solr-main-Linux/] Solr 9 is now starting
on OpenJ9, however it sounds like J9 is producing random errors in Lucene and
is unreliable:
* [https://lists.apache.org/thread/1gzzs0lmz1tc0fhc2bmvjj4qw9vx52rb]
* [https://lists.apache.org/thread/54bqt0cjmyms1x79cdbwx01bnr1lop42]
> Solr 9.0 will not start using OpenJ9
>
>
> Key: SOLR-15464
> URL: https://issues.apache.org/jira/browse/SOLR-15464
> Project: Solr
> Issue Type: Bug
>Affects Versions: 9.0
>Reporter: Colvin Cowie
>Priority: Minor
> Attachments: stacktrace.txt
>
>
> First spotted by [~krisden] on
> [https://github.com/apache/solr/pull/131#pullrequestreview-670778145] for
> SOLR-15410.
> When using an OpenJ9 JVM Solr starts correctly on branch_8x, but it does not
> start on main (9.0), producing the following error in the logs
> {noformat}
> o.a.s.c.SolrCore null:java.security.AccessControlException: Access denied
> ("java.lang.RuntimePermission" "accessClassInPackage.jdk.internal.reflect")
> ...[snip]...
> at
> org.apache.solr.common.util.JsonSchemaCreator.createObjectSchema(JsonSchemaCreator.java:82)
> at
> org.apache.solr.common.util.JsonSchemaCreator.createSchemaFromType(JsonSchemaCreator.java:71)
> at
> org.apache.solr.common.util.JsonSchemaCreator.getSchema(JsonSchemaCreator.java:54)
> at org.apache.solr.api.AnnotatedApi.createSchema(AnnotatedApi.java:358)
> at
> org.apache.solr.api.AnnotatedApi.lambda$readSpec$0(AnnotatedApi.java:176)
> at
> org.apache.solr.api.AnnotatedApi$$Lambda$179/0x.getSpec(Unknown
> Source)
> ...{noformat}
> See the full [^stacktrace.txt]
> For some additional context, a similar issue was previously reported on
> SOLR-14598 against 8.6, and was resolved by SOLR-14404
--
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
[jira] [Created] (SOLR-16922) Scripts wrongly prohibit embedded zookeeper when solr port is between 55535 and 64535
Colvin Cowie created SOLR-16922: --- Summary: Scripts wrongly prohibit embedded zookeeper when solr port is between 55535 and 64535 Key: SOLR-16922 URL: https://issues.apache.org/jira/browse/SOLR-16922 Project: Solr Issue Type: Improvement Security Level: Public (Default Security Level. Issues are Public) Affects Versions: 9.2.1, 9.3, 9.2 Reporter: Colvin Cowie Reported by [~Tiziano.DE] : https://issues.apache.org/jira/browse/SOLR-9698?focusedCommentId=17740214&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-17740214 The embedded ZK_HOST port check wrongly uses an offset of 10_000, rather than 1_000 when checking to see whether the embedded ZooKeeper port will be valid. It should check against 64_535 rather than 55_535. -- 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
[jira] [Commented] (SOLR-9698) Fix bin/solr script calculations - start/stop wait time and RMI_PORT on Windows
[ https://issues.apache.org/jira/browse/SOLR-9698?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17751695#comment-17751695 ] Colvin Cowie commented on SOLR-9698: Sorry I wasn't watching this issue in Jira so didn't see some of the comments. So with regard to [~Tiziano.DE]'s comment, I think what's happened there is that I have accidentally used the offset for the RMI port (which is SOLR_PORT+10_000), instead of the offset for the zookeeper port (SOLR_PORT+1_000). The checks for the RMI port look okay, [https://github.com/apache/solr/blob/9c911e7337cd1026accc1a825e26906039982328/solr/bin/solr.cmd#L1057-L1058] [https://github.com/apache/solr/blob/9c911e7337cd1026accc1a825e26906039982328/solr/bin/solr#L1681-L1682] so I've raised an issue for the embedded ZK Port - https://issues.apache.org/jira/browse/SOLR-16922 > Fix bin/solr script calculations - start/stop wait time and RMI_PORT on > Windows > --- > > Key: SOLR-9698 > URL: https://issues.apache.org/jira/browse/SOLR-9698 > Project: Solr > Issue Type: Improvement > Components: scripts and tools >Reporter: Erick Erickson >Priority: Major > Attachments: SOLR-9698.patch, image-2023-07-05-15-29-19-394.png > > Time Spent: 0.5h > Remaining Estimate: 0h > > Killing the Solr process after 5 seconds is too harsh. See the discussion at > SOLR-9371. > SOLR-9371 fixes the *nix versions, we need to do something similar for > Windows. -- 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
[jira] [Updated] (SOLR-9698) Fix bin/solr script calculations - start/stop wait time and RMI_PORT on Windows
[ https://issues.apache.org/jira/browse/SOLR-9698?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Colvin Cowie updated SOLR-9698: --- Resolution: Done Status: Resolved (was: Patch Available) > Fix bin/solr script calculations - start/stop wait time and RMI_PORT on > Windows > --- > > Key: SOLR-9698 > URL: https://issues.apache.org/jira/browse/SOLR-9698 > Project: Solr > Issue Type: Improvement > Components: scripts and tools >Reporter: Erick Erickson >Priority: Major > Attachments: SOLR-9698.patch, image-2023-07-05-15-29-19-394.png > > Time Spent: 0.5h > Remaining Estimate: 0h > > Killing the Solr process after 5 seconds is too harsh. See the discussion at > SOLR-9371. > SOLR-9371 fixes the *nix versions, we need to do something similar for > Windows. -- 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
[jira] [Assigned] (SOLR-16922) Scripts wrongly prohibit embedded zookeeper when solr port is between 55535 and 64535
[ https://issues.apache.org/jira/browse/SOLR-16922?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Colvin Cowie reassigned SOLR-16922: --- Assignee: Colvin Cowie > Scripts wrongly prohibit embedded zookeeper when solr port is between 55535 > and 64535 > - > > Key: SOLR-16922 > URL: https://issues.apache.org/jira/browse/SOLR-16922 > Project: Solr > Issue Type: Improvement > Security Level: Public(Default Security Level. Issues are Public) >Affects Versions: 9.2, 9.3, 9.2.1 >Reporter: Colvin Cowie >Assignee: Colvin Cowie >Priority: Trivial > > Reported by [~Tiziano.DE] : > https://issues.apache.org/jira/browse/SOLR-9698?focusedCommentId=17740214&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-17740214 > > The embedded ZK_HOST port check wrongly uses an offset of 10_000, rather than > 1_000 when checking to see whether the embedded ZooKeeper port will be valid. > It should check against 64_535 rather than 55_535. -- 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
[jira] [Updated] (SOLR-16922) Scripts wrongly prohibit embedded zookeeper when solr port is between 55535 and 64535
[ https://issues.apache.org/jira/browse/SOLR-16922?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Colvin Cowie updated SOLR-16922: Fix Version/s: 9.4 > Scripts wrongly prohibit embedded zookeeper when solr port is between 55535 > and 64535 > - > > Key: SOLR-16922 > URL: https://issues.apache.org/jira/browse/SOLR-16922 > Project: Solr > Issue Type: Improvement > Security Level: Public(Default Security Level. Issues are Public) >Affects Versions: 9.2, 9.3, 9.2.1 >Reporter: colvinco#1 >Assignee: colvinco#1 >Priority: Trivial > Fix For: 9.4 > > Time Spent: 20m > Remaining Estimate: 0h > > Reported by [~Tiziano.DE] : > https://issues.apache.org/jira/browse/SOLR-9698?focusedCommentId=17740214&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-17740214 > > The embedded ZK_HOST port check wrongly uses an offset of 10_000, rather than > 1_000 when checking to see whether the embedded ZooKeeper port will be valid. > It should check against 64_535 rather than 55_535. -- 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
[jira] [Resolved] (SOLR-16922) Scripts wrongly prohibit embedded zookeeper when solr port is between 55535 and 64535
[ https://issues.apache.org/jira/browse/SOLR-16922?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Colvin Cowie resolved SOLR-16922. - Assignee: Colvin Cowie (was: colvinco#1) Resolution: Fixed > Scripts wrongly prohibit embedded zookeeper when solr port is between 55535 > and 64535 > - > > Key: SOLR-16922 > URL: https://issues.apache.org/jira/browse/SOLR-16922 > Project: Solr > Issue Type: Improvement > Security Level: Public(Default Security Level. Issues are Public) >Affects Versions: 9.2, 9.3, 9.2.1 >Reporter: colvinco#1 >Assignee: Colvin Cowie >Priority: Trivial > Fix For: 9.4 > > Time Spent: 20m > Remaining Estimate: 0h > > Reported by [~Tiziano.DE] : > https://issues.apache.org/jira/browse/SOLR-9698?focusedCommentId=17740214&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-17740214 > > The embedded ZK_HOST port check wrongly uses an offset of 10_000, rather than > 1_000 when checking to see whether the embedded ZooKeeper port will be valid. > It should check against 64_535 rather than 55_535. -- 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
[jira] [Created] (SOLR-16958) Spurious warning logged when using latest luceneMatchVersion
Colvin Cowie created SOLR-16958:
---
Summary: Spurious warning logged when using latest
luceneMatchVersion
Key: SOLR-16958
URL: https://issues.apache.org/jira/browse/SOLR-16958
Project: Solr
Issue Type: Bug
Security Level: Public (Default Security Level. Issues are Public)
Affects Versions: 9.2.1, 9.3, 9.2
Reporter: Colvin Cowie
Assignee: Colvin Cowie
Moving to Solr 9.3 I specified
{{9.7.0}}
In the logs I saw
|SolrConfig|You should not use LATEST as luceneMatchVersion property: if you
use this setting, and then Solr upgrades to a newer release of
Lucene, sizable changes may happen. If precise back compatibility is
important then you should instead explicitly specify an actual Lucene version.|
That's a result of
[https://github.com/apache/solr/commit/05f61f60bb631662035439f84edf5df9e06b5790#r126093986]
changing the comparison to use equals() rather than == as it did previously.
--
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
[jira] [Resolved] (SOLR-13396) SolrCloud will delete the core data for any core that is not referenced in the clusterstate
[ https://issues.apache.org/jira/browse/SOLR-13396?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Colvin Cowie resolved SOLR-13396. - Fix Version/s: 9.3 Resolution: Fixed > SolrCloud will delete the core data for any core that is not referenced in > the clusterstate > --- > > Key: SOLR-13396 > URL: https://issues.apache.org/jira/browse/SOLR-13396 > Project: Solr > Issue Type: Bug > Components: SolrCloud >Affects Versions: 7.3.1, 8.0 >Reporter: Shawn Heisey >Priority: Major > Fix For: 9.3 > > Time Spent: 1.5h > Remaining Estimate: 0h > > SOLR-12066 is an improvement designed to delete core data for replicas that > were deleted while the node was down -- better cleanup. > In practice, that change causes SolrCloud to delete all core data for cores > that are not referenced in the ZK clusterstate. If all the ZK data gets > deleted or the Solr instance is pointed at a ZK ensemble with no data, it > will proceed to delete all of the cores in the solr home, with no possibility > of recovery. > I do not think that Solr should ever delete core data unless an explicit > DELETE action has been made and the node is operational at the time of the > request. If a core exists during startup that cannot be found in the ZK > clusterstate, it should be ignored (not started) and a helpful message should > be logged. I think that message should probably be at WARN so that it shows > up in the admin UI logging tab with default settings. -- 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
[jira] [Commented] (SOLR-13396) SolrCloud will delete the core data for any core that is not referenced in the clusterstate
[ https://issues.apache.org/jira/browse/SOLR-13396?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17761310#comment-17761310 ] Colvin Cowie commented on SOLR-13396: - >From 9.3 onwards this functionality is no longer enabled by default >[https://solr.apache.org/guide/solr/latest/upgrade-notes/major-changes-in-solr-9.html#deletion-of-unknown-cores-is-now-disabled-by-default] > if there's any desire to improve the functionality when it is enabled then >raise a new issue. > SolrCloud will delete the core data for any core that is not referenced in > the clusterstate > --- > > Key: SOLR-13396 > URL: https://issues.apache.org/jira/browse/SOLR-13396 > Project: Solr > Issue Type: Bug > Components: SolrCloud >Affects Versions: 7.3.1, 8.0 >Reporter: Shawn Heisey >Priority: Major > Fix For: 9.3 > > Time Spent: 1.5h > Remaining Estimate: 0h > > SOLR-12066 is an improvement designed to delete core data for replicas that > were deleted while the node was down -- better cleanup. > In practice, that change causes SolrCloud to delete all core data for cores > that are not referenced in the ZK clusterstate. If all the ZK data gets > deleted or the Solr instance is pointed at a ZK ensemble with no data, it > will proceed to delete all of the cores in the solr home, with no possibility > of recovery. > I do not think that Solr should ever delete core data unless an explicit > DELETE action has been made and the node is operational at the time of the > request. If a core exists during startup that cannot be found in the ZK > clusterstate, it should be ignored (not started) and a helpful message should > be logged. I think that message should probably be at WARN so that it shows > up in the admin UI logging tab with default settings. -- 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
[jira] [Closed] (SOLR-13396) SolrCloud will delete the core data for any core that is not referenced in the clusterstate
[ https://issues.apache.org/jira/browse/SOLR-13396?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Colvin Cowie closed SOLR-13396. --- > SolrCloud will delete the core data for any core that is not referenced in > the clusterstate > --- > > Key: SOLR-13396 > URL: https://issues.apache.org/jira/browse/SOLR-13396 > Project: Solr > Issue Type: Bug > Components: SolrCloud >Affects Versions: 7.3.1, 8.0 >Reporter: Shawn Heisey >Priority: Major > Fix For: 9.3 > > Time Spent: 1.5h > Remaining Estimate: 0h > > SOLR-12066 is an improvement designed to delete core data for replicas that > were deleted while the node was down -- better cleanup. > In practice, that change causes SolrCloud to delete all core data for cores > that are not referenced in the ZK clusterstate. If all the ZK data gets > deleted or the Solr instance is pointed at a ZK ensemble with no data, it > will proceed to delete all of the cores in the solr home, with no possibility > of recovery. > I do not think that Solr should ever delete core data unless an explicit > DELETE action has been made and the node is operational at the time of the > request. If a core exists during startup that cannot be found in the ZK > clusterstate, it should be ignored (not started) and a helpful message should > be logged. I think that message should probably be at WARN so that it shows > up in the admin UI logging tab with default settings. -- 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
[jira] [Updated] (SOLR-16958) Spurious warning logged when using latest luceneMatchVersion
[
https://issues.apache.org/jira/browse/SOLR-16958?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Colvin Cowie updated SOLR-16958:
Fix Version/s: 9.4
> Spurious warning logged when using latest luceneMatchVersion
>
>
> Key: SOLR-16958
> URL: https://issues.apache.org/jira/browse/SOLR-16958
> Project: Solr
> Issue Type: Bug
> Security Level: Public(Default Security Level. Issues are Public)
>Affects Versions: 9.2, 9.3, 9.2.1
>Reporter: Colvin Cowie
>Assignee: Colvin Cowie
>Priority: Trivial
> Fix For: 9.4
>
>
> Moving to Solr 9.3 I specified
> {{9.7.0}}
> In the logs I saw
> |SolrConfig|You should not use LATEST as luceneMatchVersion property: if you
> use this setting, and then Solr upgrades to a newer release of
> Lucene, sizable changes may happen. If precise back compatibility is
> important then you should instead explicitly specify an actual Lucene
> version.|
>
> That's a result of
> [https://github.com/apache/solr/commit/05f61f60bb631662035439f84edf5df9e06b5790#r126093986]
> changing the comparison to use equals() rather than == as it did previously.
--
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
[jira] [Resolved] (SOLR-16958) Spurious warning logged when using latest luceneMatchVersion
[
https://issues.apache.org/jira/browse/SOLR-16958?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Colvin Cowie resolved SOLR-16958.
-
Resolution: Fixed
> Spurious warning logged when using latest luceneMatchVersion
>
>
> Key: SOLR-16958
> URL: https://issues.apache.org/jira/browse/SOLR-16958
> Project: Solr
> Issue Type: Bug
> Security Level: Public(Default Security Level. Issues are Public)
>Affects Versions: 9.2, 9.3, 9.2.1
>Reporter: Colvin Cowie
>Assignee: Colvin Cowie
>Priority: Trivial
> Fix For: 9.4
>
>
> Moving to Solr 9.3 I specified
> {{9.7.0}}
> In the logs I saw
> |SolrConfig|You should not use LATEST as luceneMatchVersion property: if you
> use this setting, and then Solr upgrades to a newer release of
> Lucene, sizable changes may happen. If precise back compatibility is
> important then you should instead explicitly specify an actual Lucene
> version.|
>
> That's a result of
> [https://github.com/apache/solr/commit/05f61f60bb631662035439f84edf5df9e06b5790#r126093986]
> changing the comparison to use equals() rather than == as it did previously.
--
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
[jira] [Assigned] (SOLR-16973) Fix REMOTE_JMX_OPTS not working on Windows
[ https://issues.apache.org/jira/browse/SOLR-16973?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Colvin Cowie reassigned SOLR-16973: --- Assignee: Colvin Cowie > Fix REMOTE_JMX_OPTS not working on Windows > -- > > Key: SOLR-16973 > URL: https://issues.apache.org/jira/browse/SOLR-16973 > Project: Solr > Issue Type: Bug > Security Level: Public(Default Security Level. Issues are Public) >Affects Versions: 9.2, 9.3 >Reporter: Tiziano Degaetano >Assignee: Colvin Cowie >Priority: Trivial > Time Spent: 40m > Remaining Estimate: 0h > > On windows RMI can not be enabled using the solr.in.cmd. > This is because the REMOTE_JMX_OPTS is changed in solr.cmd but it is used as > static %REMOTE_JMX_OPTS% instead using delayed expansion \!REMOTE_JMX_OPTS\! -- 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
[jira] [Resolved] (SOLR-16973) Fix REMOTE_JMX_OPTS not working on Windows
[ https://issues.apache.org/jira/browse/SOLR-16973?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Colvin Cowie resolved SOLR-16973. - Fix Version/s: 9.4 Resolution: Fixed > Fix REMOTE_JMX_OPTS not working on Windows > -- > > Key: SOLR-16973 > URL: https://issues.apache.org/jira/browse/SOLR-16973 > Project: Solr > Issue Type: Bug > Security Level: Public(Default Security Level. Issues are Public) >Affects Versions: 9.2, 9.3 >Reporter: Tiziano Degaetano >Assignee: Colvin Cowie >Priority: Trivial > Fix For: 9.4 > > Time Spent: 40m > Remaining Estimate: 0h > > On windows RMI can not be enabled using the solr.in.cmd. > This is because the REMOTE_JMX_OPTS is changed in solr.cmd but it is used as > static %REMOTE_JMX_OPTS% instead using delayed expansion \!REMOTE_JMX_OPTS\! -- 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
[jira] [Created] (SOLR-16976) ClassNotFoundException: org.apache.logging.log4j.jul.LogManager with JMX enabled
Colvin Cowie created SOLR-16976: --- Summary: ClassNotFoundException: org.apache.logging.log4j.jul.LogManager with JMX enabled Key: SOLR-16976 URL: https://issues.apache.org/jira/browse/SOLR-16976 Project: Solr Issue Type: Bug Security Level: Public (Default Security Level. Issues are Public) Affects Versions: 9.3 Reporter: Colvin Cowie When starting Solr 9.3 with remote JMX enabled, an exception is logged java.lang.ClassNotFoundException: org.apache.logging.log4j.jul.LogManager at java.base/jdk.internal.loader.BuiltinClassLoader.loadClass(BuiltinClassLoader.java:641) at java.base/jdk.internal.loader.ClassLoaders$AppClassLoader.loadClass(ClassLoaders.java:188) at java.base/java.lang.ClassLoader.loadClass(ClassLoader.java:520) at java.logging/java.util.logging.LogManager$1.run(LogManager.java:239) at java.logging/java.util.logging.LogManager$1.run(LogManager.java:223) at java.base/java.security.AccessController.doPrivileged(AccessController.java:318) at java.logging/java.util.logging.LogManager.(LogManager.java:222) at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:77) at java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) at java.base/java.lang.reflect.Method.invoke(Method.java:568) at java.management/sun.management.ManagementFactoryHelper$LoggingMXBeanAccess.getMXBeanImplementation(ManagementFactoryHelper.java:243) at java.management/sun.management.ManagementFactoryHelper$LoggingMXBeanAccess.(ManagementFactoryHelper.java:259) at java.management/sun.management.ManagementFactoryHelper$PlatformLoggingImpl.getInstance(ManagementFactoryHelper.java:339) at java.management/sun.management.ManagementFactoryHelper$PlatformLoggingImpl.(ManagementFactoryHelper.java:342) at java.management/sun.management.ManagementFactoryHelper.getPlatformLoggingMXBean(ManagementFactoryHelper.java:160) at java.management/java.lang.management.DefaultPlatformMBeanProvider$9.nameToMBeanMap(DefaultPlatformMBeanProvider.java:378) at java.management/java.lang.management.ManagementFactory.lambda$getPlatformMBeanServer$0(ManagementFactory.java:488) at java.base/java.util.stream.ReferencePipeline$7$1.accept(ReferencePipeline.java:273) at java.base/java.util.stream.ReferencePipeline$2$1.accept(ReferencePipeline.java:179) at java.base/java.util.HashMap$ValueSpliterator.forEachRemaining(HashMap.java:1779) at java.base/java.util.stream.AbstractPipeline.copyInto(AbstractPipeline.java:509) at java.base/java.util.stream.AbstractPipeline.wrapAndCopyInto(AbstractPipeline.java:499) at java.base/java.util.stream.ForEachOps$ForEachOp.evaluateSequential(ForEachOps.java:150) at java.base/java.util.stream.ForEachOps$ForEachOp$OfRef.evaluateSequential(ForEachOps.java:173) at java.base/java.util.stream.AbstractPipeline.evaluate(AbstractPipeline.java:234) at java.base/java.util.stream.ReferencePipeline.forEach(ReferencePipeline.java:596) at java.management/java.lang.management.ManagementFactory.getPlatformMBeanServer(ManagementFactory.java:489) at jdk.management.agent/sun.management.jmxremote.ConnectorBootstrap.startRemoteConnectorServer(ConnectorBootstrap.java:476) at jdk.management.agent/jdk.internal.agent.Agent.startAgent(Agent.java:447) at jdk.management.agent/jdk.internal.agent.Agent.startAgent(Agent.java:599) Waiting up to 30 seconds to see Solr running on port 8983 Started Solr server on port 8983. Happy searching! Solr Node (id node1) on port 8983: Started -- 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
[jira] [Updated] (SOLR-16976) ClassNotFoundException: org.apache.logging.log4j.jul.LogManager with JMX enabled
[
https://issues.apache.org/jira/browse/SOLR-16976?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Colvin Cowie updated SOLR-16976:
Description:
When starting Solr 9.3 with remote JMX enabled, an exception is logged
{{java.lang.ClassNotFoundException: org.apache.logging.log4j.jul.LogManager}}
{{at
java.base/jdk.internal.loader.BuiltinClassLoader.loadClass(BuiltinClassLoader.java:641)}}
{{at
java.base/jdk.internal.loader.ClassLoaders$AppClassLoader.loadClass(ClassLoaders.java:188)}}
{{at java.base/java.lang.ClassLoader.loadClass(ClassLoader.java:520)}}
{{at java.logging/java.util.logging.LogManager$1.run(LogManager.java:239)}}
{{at java.logging/java.util.logging.LogManager$1.run(LogManager.java:223)}}
{{at
java.base/java.security.AccessController.doPrivileged(AccessController.java:318)}}
{{at java.logging/java.util.logging.LogManager.(LogManager.java:222)}}
{{at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native
Method)}}
{{at
java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:77)}}
{{at
java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)}}
{{at java.base/java.lang.reflect.Method.invoke(Method.java:568)}}
{{at
java.management/sun.management.ManagementFactoryHelper$LoggingMXBeanAccess.getMXBeanImplementation(ManagementFactoryHelper.java:243)}}
{{at
java.management/sun.management.ManagementFactoryHelper$LoggingMXBeanAccess.(ManagementFactoryHelper.java:259)}}
{{at
java.management/sun.management.ManagementFactoryHelper$PlatformLoggingImpl.getInstance(ManagementFactoryHelper.java:339)}}
{{at
java.management/sun.management.ManagementFactoryHelper$PlatformLoggingImpl.(ManagementFactoryHelper.java:342)}}
{{at
java.management/sun.management.ManagementFactoryHelper.getPlatformLoggingMXBean(ManagementFactoryHelper.java:160)}}
{{at
java.management/java.lang.management.DefaultPlatformMBeanProvider$9.nameToMBeanMap(DefaultPlatformMBeanProvider.java:378)}}
{{at
java.management/java.lang.management.ManagementFactory.lambda$getPlatformMBeanServer$0(ManagementFactory.java:488)}}
{{at
java.base/java.util.stream.ReferencePipeline$7$1.accept(ReferencePipeline.java:273)}}
{{at
java.base/java.util.stream.ReferencePipeline$2$1.accept(ReferencePipeline.java:179)}}
{{at
java.base/java.util.HashMap$ValueSpliterator.forEachRemaining(HashMap.java:1779)}}
{{at
java.base/java.util.stream.AbstractPipeline.copyInto(AbstractPipeline.java:509)}}
{{at
java.base/java.util.stream.AbstractPipeline.wrapAndCopyInto(AbstractPipeline.java:499)}}
{{at
java.base/java.util.stream.ForEachOps$ForEachOp.evaluateSequential(ForEachOps.java:150)}}
{{at
java.base/java.util.stream.ForEachOps$ForEachOp$OfRef.evaluateSequential(ForEachOps.java:173)}}
{{at
java.base/java.util.stream.AbstractPipeline.evaluate(AbstractPipeline.java:234)}}
{{at
java.base/java.util.stream.ReferencePipeline.forEach(ReferencePipeline.java:596)}}
{{at
java.management/java.lang.management.ManagementFactory.getPlatformMBeanServer(ManagementFactory.java:489)}}
{{at
jdk.management.agent/sun.management.jmxremote.ConnectorBootstrap.startRemoteConnectorServer(ConnectorBootstrap.java:476)}}
{{at jdk.management.agent/jdk.internal.agent.Agent.startAgent(Agent.java:447)}}
{{at jdk.management.agent/jdk.internal.agent.Agent.startAgent(Agent.java:599)}}
{{Waiting up to 30 seconds to see Solr running on port 8983}}
{{Started Solr server on port 8983. Happy searching!}}
{{Solr Node (id node1) on port 8983: Started}}
was:
When starting Solr 9.3 with remote JMX enabled, an exception is logged
java.lang.ClassNotFoundException: org.apache.logging.log4j.jul.LogManager
at
java.base/jdk.internal.loader.BuiltinClassLoader.loadClass(BuiltinClassLoader.java:641)
at
java.base/jdk.internal.loader.ClassLoaders$AppClassLoader.loadClass(ClassLoaders.java:188)
at java.base/java.lang.ClassLoader.loadClass(ClassLoader.java:520)
at java.logging/java.util.logging.LogManager$1.run(LogManager.java:239)
at java.logging/java.util.logging.LogManager$1.run(LogManager.java:223)
at
java.base/java.security.AccessController.doPrivileged(AccessController.java:318)
at
java.logging/java.util.logging.LogManager.(LogManager.java:222)
at
java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at
java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:77)
at
java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.base/java.lang.reflect.Method.invoke(Method.java:568)
at
java.management/sun.management.ManagementFactoryHelper$LoggingMXBeanAccess.getMXBeanImplementation(ManagementFactoryHelper.java:243)
at
java.management/sun.management.ManagementFactoryHelper$LoggingMXBeanAccess.(ManagementFactoryHelp
[jira] [Created] (SOLR-15410) GC log is directed to console when starting Solr with Java 11 Open J9 on Windows
Colvin Cowie created SOLR-15410:
---
Summary: 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
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 -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
http://www.ibm.com/j9/verbosegc"; version="741e94ea8_CMPRSS">
...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:}} syntax is replaced with
{{-Xverbosegclog:}} according to
[https://www.eclipse.org/openj9/docs/xlog/]
On Linux the bin/solr has more powerful logic for parsing the GC options and
seems to work in all cases.
However 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}}.
--
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
[jira] [Updated] (SOLR-15410) GC log is directed to console when starting Solr with Java 11 Open J9 on Windows
[
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 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 -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
http://www.ibm.com/j9/verbosegc"; version="741e94ea8_CMPRSS">
...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:}} syntax is replaced with
{{-Xverbosegclog:}} 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}
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 -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
http://www.ibm.com/j9/verbosegc"; version="741e94ea8_CMPRSS">
...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:}} syntax is replaced with
{{-Xverbosegclog:}} according to
[https://www.eclipse.org/openj9/docs/xlog/]
On Linux the bin/solr has more powerful logic for parsing the GC options and
seems to work in all cases.
However 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 v
[jira] [Commented] (SOLR-15410) GC log is directed to console when starting Solr with Java 11 Open J9 on Windows
[
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 -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
>
> http://www.ibm.com/j9/verbosegc"; version="741e94ea8_CMPRSS">
>
>
> ...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:}} syntax is replaced with
> {{-Xverbosegclog:}} 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
>
[jira] [Commented] (SOLR-15410) GC log is directed to console when starting Solr with Java 11 Open J9 on Windows
[
https://issues.apache.org/jira/browse/SOLR-15410?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17346472#comment-17346472
]
Colvin Cowie commented on SOLR-15410:
-
In the PR I've made both match on "J9" only since that's essentially what the
.cmd was doing already, but I could be more specific and match on "OpenJ9" |
"IBM J9" if necessary
> 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 -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
>
> http://www.ibm.com/j9/verbosegc"; version="741e94ea8_CMPRSS">
>
>
> ...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:}} syntax is replaced with
> {{-Xverbosegclog:}} 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
[jira] [Updated] (SOLR-15410) GC log is directed to console when starting Solr with Java 11 Open J9 on Windows
[
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 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 -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
http://www.ibm.com/j9/verbosegc"; version="741e94ea8_CMPRSS">
...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:}} syntax is replaced with
{{-Xverbosegclog:}} 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.
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 -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
http://www.ibm.com/j9/verbosegc"; version="741e94ea8_CMPRSS">
...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:}} syntax is replaced with
{{-Xverbosegclog:}} 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
[jira] [Updated] (SOLR-15410) GC log is directed to console when starting Solr with Java 11 Open J9 on Windows
[
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 -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
http://www.ibm.com/j9/verbosegc"; version="741e94ea8_CMPRSS">
...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:}} syntax is replaced with
{{-Xverbosegclog:}} 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 -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
http://www.ibm.com/j9/verbosegc"; version="741e94ea8_CMPRSS">
...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:}} syntax is replaced with
{{-Xverbosegclog:}} 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 b
[jira] [Commented] (SOLR-15410) GC log is directed to console when starting Solr with Java 11 Open J9 on Windows
[
https://issues.apache.org/jira/browse/SOLR-15410?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17346711#comment-17346711
]
Colvin Cowie commented on SOLR-15410:
-
I've made it match on "OpenJ9|IBM J9" now. ({{findstr /i /C:"IBM J9"
/C:"OpenJ9"}})
> 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 -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
>
> http://www.ibm.com/j9/verbosegc"; version="741e94ea8_CMPRSS">
>
>
> ...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:}} syntax is replaced with
> {{-Xverbosegclog:}} 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: issues-unsubscr...@solr.apache.org
For additional commands, e-mail: issues-h...@solr.apache.org
[jira] [Commented] (SOLR-15410) GC log is directed to console when starting Solr with Java 11 Open J9 on Windows
[
https://issues.apache.org/jira/browse/SOLR-15410?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17347006#comment-17347006
]
Colvin Cowie commented on SOLR-15410:
-
Thanks [~epugh]. The combinations of different JDKs with different OSs makes my
head spin a bit.
I'm using Windows natively with docker for testing on Linux. The OpenJ9 and
Hotspot JDKs are from [https://adoptopenjdk.net/archive.html] and I have access
to older IBM J9 JDKs too.
Locally I added some ECHOs to check that I was getting the right vendor for
different JDKs, and checked that the GC log appeared correctly and no error
messages appeared in the console / console log.
Luckily there's only a couple of J9 specific references in those scripts, so I
feel pretty confident that it's not going to affect anything other than the GC
log... actually looking at it now, one of the uses seems to serve no purpose:
[https://github.com/apache/solr/blob/8b92e7002f589b7426f29aa85042fd2768d46d19/solr/bin/solr.cmd#L2052-L2073]
JAVA_BUILD is initialised to 0, and gets set to an actual value when not using
J9. But the value is never read anywhere. Looks like that can be removed
> 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 -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
>
> http://www.ibm.com/j9/verbosegc"; version="741e94ea8_CMPRSS">
>
>
> ...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:}} syntax is replaced with
> {{-Xverbosegclog:}} 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: issues-uns
[jira] [Commented] (SOLR-15410) GC log is directed to console when starting Solr with Java 11 Open J9 on Windows
[
https://issues.apache.org/jira/browse/SOLR-15410?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17347010#comment-17347010
]
Colvin Cowie commented on SOLR-15410:
-
JAVA_BUILD hasn't been read since
[https://github.com/apache/solr/commit/8ae3304c8631e1ba9a14aa0fc576e13b9198dfe5#diff-118de7ae5d9fc032e479321cb4d3ee62ceb68e9f3c845292b44c5e14c0f769cf]
so I've removed it in the PR 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 -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
>
> http://www.ibm.com/j9/verbosegc"; version="741e94ea8_CMPRSS">
>
>
> ...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:}} syntax is replaced with
> {{-Xverbosegclog:}} 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: issues-unsubscr...@solr.apache.org
For additional commands, e-mail: issues-h...@solr.apache.org
[jira] [Created] (SOLR-15464) Solr 9.0 will not start using OpenJ9
Colvin Cowie created SOLR-15464:
---
Summary: Solr 9.0 will not start using OpenJ9
Key: SOLR-15464
URL: https://issues.apache.org/jira/browse/SOLR-15464
Project: Solr
Issue Type: Bug
Security Level: Public (Default Security Level. Issues are Public)
Affects Versions: main (9.0)
Reporter: Colvin Cowie
Attachments: stacktrace
First spotted by [~krisden] on
[https://github.com/apache/solr/pull/131#pullrequestreview-670778145] for
SOLR-15410.
When using an OpenJ9 JVM Solr starts correctly on branch_8x, but it does not
start on main (9.0), producing the following error in the logs
{noformat}
o.a.s.c.SolrCore null:java.security.AccessControlException: Access denied
("java.lang.RuntimePermission" "accessClassInPackage.jdk.internal.reflect")
...[snip]...
at
org.apache.solr.common.util.JsonSchemaCreator.createObjectSchema(JsonSchemaCreator.java:82)
at
org.apache.solr.common.util.JsonSchemaCreator.createSchemaFromType(JsonSchemaCreator.java:71)
at
org.apache.solr.common.util.JsonSchemaCreator.getSchema(JsonSchemaCreator.java:54)
at org.apache.solr.api.AnnotatedApi.createSchema(AnnotatedApi.java:358)
at
org.apache.solr.api.AnnotatedApi.lambda$readSpec$0(AnnotatedApi.java:176)
at
org.apache.solr.api.AnnotatedApi$$Lambda$179/0x.getSpec(Unknown
Source)
...{noformat}
See the full [^stacktrace]
For some additional context, a similar issue was previously reported on
SOLR-14598 against 8.6, and was resolved by SOLR-14404
--
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
[jira] [Updated] (SOLR-15464) Solr 9.0 will not start using OpenJ9
[
https://issues.apache.org/jira/browse/SOLR-15464?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Colvin Cowie updated SOLR-15464:
Description:
First spotted by [~krisden] on
[https://github.com/apache/solr/pull/131#pullrequestreview-670778145] for
SOLR-15410.
When using an OpenJ9 JVM Solr starts correctly on branch_8x, but it does not
start on main (9.0), producing the following error in the logs
{noformat}
o.a.s.c.SolrCore null:java.security.AccessControlException: Access denied
("java.lang.RuntimePermission" "accessClassInPackage.jdk.internal.reflect")
...[snip]...
at
org.apache.solr.common.util.JsonSchemaCreator.createObjectSchema(JsonSchemaCreator.java:82)
at
org.apache.solr.common.util.JsonSchemaCreator.createSchemaFromType(JsonSchemaCreator.java:71)
at
org.apache.solr.common.util.JsonSchemaCreator.getSchema(JsonSchemaCreator.java:54)
at org.apache.solr.api.AnnotatedApi.createSchema(AnnotatedApi.java:358)
at
org.apache.solr.api.AnnotatedApi.lambda$readSpec$0(AnnotatedApi.java:176)
at
org.apache.solr.api.AnnotatedApi$$Lambda$179/0x.getSpec(Unknown
Source)
...{noformat}
See the full [^stacktrace.txt]
For some additional context, a similar issue was previously reported on
SOLR-14598 against 8.6, and was resolved by SOLR-14404
was:
First spotted by [~krisden] on
[https://github.com/apache/solr/pull/131#pullrequestreview-670778145] for
SOLR-15410.
When using an OpenJ9 JVM Solr starts correctly on branch_8x, but it does not
start on main (9.0), producing the following error in the logs
{noformat}
o.a.s.c.SolrCore null:java.security.AccessControlException: Access denied
("java.lang.RuntimePermission" "accessClassInPackage.jdk.internal.reflect")
...[snip]...
at
org.apache.solr.common.util.JsonSchemaCreator.createObjectSchema(JsonSchemaCreator.java:82)
at
org.apache.solr.common.util.JsonSchemaCreator.createSchemaFromType(JsonSchemaCreator.java:71)
at
org.apache.solr.common.util.JsonSchemaCreator.getSchema(JsonSchemaCreator.java:54)
at org.apache.solr.api.AnnotatedApi.createSchema(AnnotatedApi.java:358)
at
org.apache.solr.api.AnnotatedApi.lambda$readSpec$0(AnnotatedApi.java:176)
at
org.apache.solr.api.AnnotatedApi$$Lambda$179/0x.getSpec(Unknown
Source)
...{noformat}
See the full [^stacktrace]
For some additional context, a similar issue was previously reported on
SOLR-14598 against 8.6, and was resolved by SOLR-14404
> Solr 9.0 will not start using OpenJ9
>
>
> Key: SOLR-15464
> URL: https://issues.apache.org/jira/browse/SOLR-15464
> Project: Solr
> Issue Type: Bug
> Security Level: Public(Default Security Level. Issues are Public)
>Affects Versions: main (9.0)
>Reporter: Colvin Cowie
>Priority: Minor
> Attachments: stacktrace.txt
>
>
> First spotted by [~krisden] on
> [https://github.com/apache/solr/pull/131#pullrequestreview-670778145] for
> SOLR-15410.
> When using an OpenJ9 JVM Solr starts correctly on branch_8x, but it does not
> start on main (9.0), producing the following error in the logs
> {noformat}
> o.a.s.c.SolrCore null:java.security.AccessControlException: Access denied
> ("java.lang.RuntimePermission" "accessClassInPackage.jdk.internal.reflect")
> ...[snip]...
> at
> org.apache.solr.common.util.JsonSchemaCreator.createObjectSchema(JsonSchemaCreator.java:82)
> at
> org.apache.solr.common.util.JsonSchemaCreator.createSchemaFromType(JsonSchemaCreator.java:71)
> at
> org.apache.solr.common.util.JsonSchemaCreator.getSchema(JsonSchemaCreator.java:54)
> at org.apache.solr.api.AnnotatedApi.createSchema(AnnotatedApi.java:358)
> at
> org.apache.solr.api.AnnotatedApi.lambda$readSpec$0(AnnotatedApi.java:176)
> at
> org.apache.solr.api.AnnotatedApi$$Lambda$179/0x.getSpec(Unknown
> Source)
> ...{noformat}
> See the full [^stacktrace.txt]
> For some additional context, a similar issue was previously reported on
> SOLR-14598 against 8.6, and was resolved by SOLR-14404
--
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
[jira] [Updated] (SOLR-15464) Solr 9.0 will not start using OpenJ9
[
https://issues.apache.org/jira/browse/SOLR-15464?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Colvin Cowie updated SOLR-15464:
Attachment: stacktrace.txt
> Solr 9.0 will not start using OpenJ9
>
>
> Key: SOLR-15464
> URL: https://issues.apache.org/jira/browse/SOLR-15464
> Project: Solr
> Issue Type: Bug
> Security Level: Public(Default Security Level. Issues are Public)
>Affects Versions: main (9.0)
>Reporter: Colvin Cowie
>Priority: Minor
> Attachments: stacktrace.txt
>
>
> First spotted by [~krisden] on
> [https://github.com/apache/solr/pull/131#pullrequestreview-670778145] for
> SOLR-15410.
> When using an OpenJ9 JVM Solr starts correctly on branch_8x, but it does not
> start on main (9.0), producing the following error in the logs
> {noformat}
> o.a.s.c.SolrCore null:java.security.AccessControlException: Access denied
> ("java.lang.RuntimePermission" "accessClassInPackage.jdk.internal.reflect")
> ...[snip]...
> at
> org.apache.solr.common.util.JsonSchemaCreator.createObjectSchema(JsonSchemaCreator.java:82)
> at
> org.apache.solr.common.util.JsonSchemaCreator.createSchemaFromType(JsonSchemaCreator.java:71)
> at
> org.apache.solr.common.util.JsonSchemaCreator.getSchema(JsonSchemaCreator.java:54)
> at org.apache.solr.api.AnnotatedApi.createSchema(AnnotatedApi.java:358)
> at
> org.apache.solr.api.AnnotatedApi.lambda$readSpec$0(AnnotatedApi.java:176)
> at
> org.apache.solr.api.AnnotatedApi$$Lambda$179/0x.getSpec(Unknown
> Source)
> ...{noformat}
> See the full [^stacktrace]
> For some additional context, a similar issue was previously reported on
> SOLR-14598 against 8.6, and was resolved by SOLR-14404
--
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
[jira] [Updated] (SOLR-15464) Solr 9.0 will not start using OpenJ9
[
https://issues.apache.org/jira/browse/SOLR-15464?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Colvin Cowie updated SOLR-15464:
Attachment: (was: stacktrace)
> Solr 9.0 will not start using OpenJ9
>
>
> Key: SOLR-15464
> URL: https://issues.apache.org/jira/browse/SOLR-15464
> Project: Solr
> Issue Type: Bug
> Security Level: Public(Default Security Level. Issues are Public)
>Affects Versions: main (9.0)
>Reporter: Colvin Cowie
>Priority: Minor
> Attachments: stacktrace.txt
>
>
> First spotted by [~krisden] on
> [https://github.com/apache/solr/pull/131#pullrequestreview-670778145] for
> SOLR-15410.
> When using an OpenJ9 JVM Solr starts correctly on branch_8x, but it does not
> start on main (9.0), producing the following error in the logs
> {noformat}
> o.a.s.c.SolrCore null:java.security.AccessControlException: Access denied
> ("java.lang.RuntimePermission" "accessClassInPackage.jdk.internal.reflect")
> ...[snip]...
> at
> org.apache.solr.common.util.JsonSchemaCreator.createObjectSchema(JsonSchemaCreator.java:82)
> at
> org.apache.solr.common.util.JsonSchemaCreator.createSchemaFromType(JsonSchemaCreator.java:71)
> at
> org.apache.solr.common.util.JsonSchemaCreator.getSchema(JsonSchemaCreator.java:54)
> at org.apache.solr.api.AnnotatedApi.createSchema(AnnotatedApi.java:358)
> at
> org.apache.solr.api.AnnotatedApi.lambda$readSpec$0(AnnotatedApi.java:176)
> at
> org.apache.solr.api.AnnotatedApi$$Lambda$179/0x.getSpec(Unknown
> Source)
> ...{noformat}
> See the full [^stacktrace]
> For some additional context, a similar issue was previously reported on
> SOLR-14598 against 8.6, and was resolved by SOLR-14404
--
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
[jira] [Commented] (SOLR-13396) SolrCloud will delete the core data for any core that is not referenced in the clusterstate
[
https://issues.apache.org/jira/browse/SOLR-13396?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17479982#comment-17479982
]
Colvin Cowie commented on SOLR-13396:
-
I couldn't wait for something to be done / agreement to be reached on what to
do with this issue, so the workaround I used in my product was to subclass the
{{org.apache.solr.core.CoreContainer}} and override the {{unload(String,
boolean, boolean, boolean)}} method so that it doesn't delete a core in this
scenario. (I also subclass {{org.apache.solr.servlet.SolrDispatchFilter}}
[which is specified in the web.xml] and override {{createCoreContainer(Path,
Properties)}} which is where I call my overridden core container from, which
means modifying the ).
It's almost 3 years since this was raised. If nothing else, could we at least
have a flag that can be used to disable this destructive by default behaviour
through the solr.in?
> SolrCloud will delete the core data for any core that is not referenced in
> the clusterstate
> ---
>
> Key: SOLR-13396
> URL: https://issues.apache.org/jira/browse/SOLR-13396
> Project: Solr
> Issue Type: Bug
> Components: SolrCloud
>Affects Versions: 7.3.1, 8.0
>Reporter: Shawn Heisey
>Priority: Major
>
> SOLR-12066 is an improvement designed to delete core data for replicas that
> were deleted while the node was down -- better cleanup.
> In practice, that change causes SolrCloud to delete all core data for cores
> that are not referenced in the ZK clusterstate. If all the ZK data gets
> deleted or the Solr instance is pointed at a ZK ensemble with no data, it
> will proceed to delete all of the cores in the solr home, with no possibility
> of recovery.
> I do not think that Solr should ever delete core data unless an explicit
> DELETE action has been made and the node is operational at the time of the
> request. If a core exists during startup that cannot be found in the ZK
> clusterstate, it should be ignored (not started) and a helpful message should
> be logged. I think that message should probably be at WARN so that it shows
> up in the admin UI logging tab with default settings.
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
-
To unsubscribe, e-mail: issues-unsubscr...@solr.apache.org
For additional commands, e-mail: issues-h...@solr.apache.org
[jira] [Comment Edited] (SOLR-13396) SolrCloud will delete the core data for any core that is not referenced in the clusterstate
[
https://issues.apache.org/jira/browse/SOLR-13396?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17479982#comment-17479982
]
Colvin Cowie edited comment on SOLR-13396 at 1/21/22, 10:30 AM:
I couldn't wait for something to be done / agreement to be reached on what to
do with this issue, so the workaround I used in my product was to subclass the
{{org.apache.solr.core.CoreContainer}} and override the {{unload(String,
boolean, boolean, boolean)}} method so that it doesn't delete a core in this
scenario. (I also subclass {{org.apache.solr.servlet.SolrDispatchFilter}}
[which is specified in the web.xml] and override {{createCoreContainer(Path,
Properties)}} which is where I call my overridden core container from).
It's almost 3 years since this was raised. If nothing else, could we at least
have a flag that can be used to disable this destructive by default behaviour
through the solr.in?
was (Author: cjcowie):
I couldn't wait for something to be done / agreement to be reached on what to
do with this issue, so the workaround I used in my product was to subclass the
{{org.apache.solr.core.CoreContainer}} and override the {{unload(String,
boolean, boolean, boolean)}} method so that it doesn't delete a core in this
scenario. (I also subclass {{org.apache.solr.servlet.SolrDispatchFilter}}
[which is specified in the web.xml] and override {{createCoreContainer(Path,
Properties)}} which is where I call my overridden core container from, which
means modifying the ).
It's almost 3 years since this was raised. If nothing else, could we at least
have a flag that can be used to disable this destructive by default behaviour
through the solr.in?
> SolrCloud will delete the core data for any core that is not referenced in
> the clusterstate
> ---
>
> Key: SOLR-13396
> URL: https://issues.apache.org/jira/browse/SOLR-13396
> Project: Solr
> Issue Type: Bug
> Components: SolrCloud
>Affects Versions: 7.3.1, 8.0
>Reporter: Shawn Heisey
>Priority: Major
>
> SOLR-12066 is an improvement designed to delete core data for replicas that
> were deleted while the node was down -- better cleanup.
> In practice, that change causes SolrCloud to delete all core data for cores
> that are not referenced in the ZK clusterstate. If all the ZK data gets
> deleted or the Solr instance is pointed at a ZK ensemble with no data, it
> will proceed to delete all of the cores in the solr home, with no possibility
> of recovery.
> I do not think that Solr should ever delete core data unless an explicit
> DELETE action has been made and the node is operational at the time of the
> request. If a core exists during startup that cannot be found in the ZK
> clusterstate, it should be ignored (not started) and a helpful message should
> be logged. I think that message should probably be at WARN so that it shows
> up in the admin UI logging tab with default settings.
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
-
To unsubscribe, e-mail: issues-unsubscr...@solr.apache.org
For additional commands, e-mail: issues-h...@solr.apache.org
[jira] [Created] (SOLR-15558) Solr stop doesn't handle zombie processes
Colvin Cowie created SOLR-15558:
---
Summary: Solr stop doesn't handle zombie processes
Key: SOLR-15558
URL: https://issues.apache.org/jira/browse/SOLR-15558
Project: Solr
Issue Type: Bug
Security Level: Public (Default Security Level. Issues are Public)
Reporter: Colvin Cowie
When calling solr stop on linux, this command is used
_CHECK_PID=`ps auxww | awk '\{print $2}' | grep -w $SOLR_PID | sort -r | tr -d
' '`_
[https://github.com/apache/solr/blob/122c88a0748769432ef62cc3fb94c2226dd67aa7/solr/bin/solr#L871]
If Solr has stopped but remains as a zombie process then its process entry will
remain in the table, so _ps auxww_ will continue to show the PID even after
kill -9. So that results in something like this, with 3 minutes wasted waiting
for a dead process to exit.
_[2021-07-21T09:15:12.365Z] Sending stop command to Solr running on port 8983
... waiting up to 180 seconds to allow Jetty process 12622 to stop gracefully._
_[2021-07-21T09:18:13.551Z] [|] Solr process 12622 is still running; jstacking
it now._
_[2021-07-21T09:18:21.806Z] 12622: Unable to open socket file
/proc/12622/root/tmp/.java_pid12622: target process 12622 doesn't respond
within 10500ms or HotSpot VM not loaded_
_[2021-07-21T09:18:21.806Z] Solr process 12622 is still running; forcefully
killing it now._
_[2021-07-21T09:18:21.806Z] Killed process 12622_
_[2021-07-21T09:18:31.678Z] ERROR: Failed to kill previous Solr Java process
12622 ... script fails._
But the output of ps auxww does identify Zombie processes under STAT:
_USER PID %CPU %MEM VSZ RSS TTY *STAT* START TIME COMMAND_
_root 12622 1.4 0.0 0 0 pts/1 *Z*
10:42 0:26 [java] ** _
So the CHECK_PID could filter out Zombies.
Obviously the bigger issue is why the process has ended up as a Zombie (in this
case it was because of
[https://blog.phusion.nl/2015/01/20/docker-and-the-pid-1-zombie-reaping-problem/]
and not specifying "--init" when running Solr inside a docker container) so
maybe a message warning that the process is a zombie is worth having, so that
the user has an opportunity to do something about it.
Note from [~mdrob]
{quote}That seems like a reasonable check to add, the only caution I would
advise
is that a lot of developers use macs for local testing so make sure that
whatever flags you invoke are generally cross platform compatible, or
hidden behind appropriate conditions.{quote}
--
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
[jira] [Commented] (SOLR-15410) GC log is directed to console when starting Solr with Java 11 Open J9 on Windows
[
https://issues.apache.org/jira/browse/SOLR-15410?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17404627#comment-17404627
]
Colvin Cowie commented on SOLR-15410:
-
Can we get this merged into 8.10, assuming that's happening? [~epugh]
> 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
>Reporter: Colvin Cowie
>Assignee: David Eric Pugh
>Priority: Minor
> Fix For: main (9.0)
>
> Time Spent: 1h 50m
> 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 -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
>
> http://www.ibm.com/j9/verbosegc"; version="741e94ea8_CMPRSS">
>
>
> ...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:}} syntax is replaced with
> {{-Xverbosegclog:}} 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: issues-unsubscr...@solr.apache.org
For additional commands, e-mail: issues-h...@solr.apache.org
[jira] [Commented] (SOLR-15410) GC log is directed to console when starting Solr with Java 11 Open J9 on Windows
[
https://issues.apache.org/jira/browse/SOLR-15410?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17404729#comment-17404729
]
Colvin Cowie commented on SOLR-15410:
-
Okay sure, I'll do that tomorrow. Thanks
> 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
>Reporter: Colvin Cowie
>Assignee: David Eric Pugh
>Priority: Minor
> Fix For: main (9.0)
>
> Time Spent: 1h 50m
> 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 -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
>
> http://www.ibm.com/j9/verbosegc"; version="741e94ea8_CMPRSS">
>
>
> ...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:}} syntax is replaced with
> {{-Xverbosegclog:}} 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: issues-unsubscr...@solr.apache.org
For additional commands, e-mail: issues-h...@solr.apache.org
[jira] [Commented] (SOLR-15410) GC log is directed to console when starting Solr with Java 11 Open J9 on Windows
[
https://issues.apache.org/jira/browse/SOLR-15410?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17405220#comment-17405220
]
Colvin Cowie commented on SOLR-15410:
-
I've opened https://github.com/apache/lucene-solr/pull/2560
> 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
>Reporter: Colvin Cowie
>Assignee: David Eric Pugh
>Priority: Minor
> Fix For: main (9.0)
>
> Time Spent: 2h
> 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 -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
>
> http://www.ibm.com/j9/verbosegc"; version="741e94ea8_CMPRSS">
>
>
> ...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:}} syntax is replaced with
> {{-Xverbosegclog:}} 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: issues-unsubscr...@solr.apache.org
For additional commands, e-mail: issues-h...@solr.apache.org
[jira] [Created] (SOLR-17644) Collection creation fails when replica placement plugin and basic auth are enabled
Colvin Cowie created SOLR-17644:
---
Summary: Collection creation fails when replica placement plugin
and basic auth are enabled
Key: SOLR-17644
URL: https://issues.apache.org/jira/browse/SOLR-17644
Project: Solr
Issue Type: Bug
Security Level: Public (Default Security Level. Issues are Public)
Affects Versions: 9.8, main (10.0)
Reporter: Colvin Cowie
In Solr 9.8 and latest, collection creation fails when the replica placement
plugin and authentication are both configured. See
[https://the-asf.slack.com/archives/CEKUCUNE9/p1738152813677179] for more info
Stacktrace:
{quote}2025-01-29 11:42:40.638 WARN (OverseerThreadFactory-22-thread-1)
[c:main_index s: r: x: t:] o.a.s.c.s.i.SolrClientNodeStateProvider could not
get tags from node localhost:8983_solr =>
org.apache.solr.client.solrj.impl.BaseHttpSolrClient$RemoteSolrException: Error
from server at
http://localhost:8983/solr/admin/metrics
: Expected mime type in [application/octet-stream,
application/vnd.apache.solr.javabin] but got text/html.
Error 401 require authentication
HTTP ERROR 401 require authentication
URI:/solr/admin/metrics
STATUS:401
MESSAGE:require authentication
SERVLET:default
at
org.apache.solr.client.solrj.impl.HttpSolrClientBase.checkContentType(HttpSolrClientBase.java:341)
org.apache.solr.client.solrj.impl.BaseHttpSolrClient$RemoteSolrException: Error
from server at
http://localhost:8983/solr/admin/metrics
: Expected mime type in [application/octet-stream,
application/vnd.apache.solr.javabin] but got text/html.
Error 401 require authentication
HTTP ERROR 401 require authentication
URI:/solr/admin/metrics
STATUS:401
MESSAGE:require authentication
SERVLET:default
at
org.apache.solr.client.solrj.impl.HttpSolrClientBase.checkContentType(HttpSolrClientBase.java:341)
~[?:?]
at
org.apache.solr.client.solrj.impl.HttpSolrClientBase.processErrorsAndResponse(HttpSolrClientBase.java:227)
~[?:?]
at
org.apache.solr.client.solrj.impl.Http2SolrClient.processErrorsAndResponse(Http2SolrClient.java:621)
~[?:?]
at
org.apache.solr.client.solrj.impl.Http2SolrClient.request(Http2SolrClient.java:542)
~[?:?]
at org.apache.solr.client.solrj.SolrRequest.process(SolrRequest.java:279) ~[?:?]
at org.apache.solr.client.solrj.SolrRequest.process(SolrRequest.java:295) ~[?:?]
at
org.apache.solr.client.solrj.impl.Http2SolrClient.requestWithBaseUrl(Http2SolrClient.java:604)
~[?:?]
at
org.apache.solr.client.solrj.impl.SolrClientNodeStateProvider$RemoteCallCtx.invoke(SolrClientNodeStateProvider.java:292)
~[?:?]
at
org.apache.solr.client.solrj.impl.SolrClientNodeStateProvider$RemoteCallCtx.invokeWithRetry(SolrClientNodeStateProvider.java:255)
~[?:?]
at
org.apache.solr.client.solrj.impl.SolrClientNodeStateProvider.fetchReplicaMetrics(SolrClientNodeStateProvider.java:190)
~[?:?]
at
org.apache.solr.client.solrj.impl.NodeValueFetcher.getRemotePropertiesAndMetrics(NodeValueFetcher.java:125)
~[?:?]
at
org.apache.solr.client.solrj.impl.NodeValueFetcher.getTags(NodeValueFetcher.java:187)
~[?:?]
at
org.apache.solr.client.solrj.impl.SolrClientNodeStateProvider.fetchTagValues(SolrClientNodeStateProvider.java:114)
~[?:?]
at
org.apache.solr.client.solrj.impl.SolrClientNodeStateProvider.getNodeValues(SolrClientNodeStateProvider.java:106)
~[?:?]
at
org.apache.solr.cluster.placement.impl.AttributeFetcherImpl.fetchAttributes(AttributeFetcherImpl.java:149)
~[?:?]
at
org.apache.solr.cluster.placement.plugins.AffinityPlacementFactory$AffinityPlacementPlugin.getBaseWeightedNodes(AffinityPlacementFactory.java:284)
~[?:?]
at
org.apache.solr.cluster.placement.plugins.OrderedNodePlacementPlugin.getWeightedNodes(OrderedNodePlacementPlugin.java:316)
~[?:?]
at
org.apache.solr.cluster.placement.plugins.OrderedNodePlacementPlugin.computePlacements(OrderedNodePlacementPlugin.java:88)
~[?:?]
at
org.apache.solr.cluster.placement.impl.PlacementPluginAssignStrategy.assign(PlacementPluginAssignStrategy.java:84)
~[?:?]
at
org.apache.solr.cloud.api.collections.Assign$AssignStrategy.assign(Assign.java:432)
~[?:?]
at
org.apache.solr.cloud.api.collections.CreateCollectionCmd.buildReplicaPositions(CreateCollectionCmd.java:537)
~[?:?]
at
org.apache.solr.cloud.api.collections.CreateCollectionCmd.call(CreateCollectionCmd.java:234)
~[?:?]
at
org.apache.solr.cloud.api.collections.CollApiCmds$TraceAwareCommand.call(CollApiCmds.java:225)
~[?:?]
at
org.apache.solr.cloud.api.collections.OverseerCollectionMessageHandler.processMessage(OverseerCollectionMessageHandler.java:130)
~[?:?]
at
org.apache.solr.cloud.OverseerTaskProcessor$Runner.run(OverseerTaskProcessor.java:564)
~[?:?]
at
org.apache.solr.common.util.ExecutorUtil$MDCAwareThreadPoolExecutor.lambda$execute$0(ExecutorUtil.java:380)
~[?:?]
at
java.base/java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1136)
~[?:?]
at
java.base/java.util.
[jira] [Created] (SOLR-17617) v2 CollectionProp and InstallCoreData APIs are broken
Colvin Cowie created SOLR-17617:
---
Summary: v2 CollectionProp and InstallCoreData APIs are broken
Key: SOLR-17617
URL: https://issues.apache.org/jira/browse/SOLR-17617
Project: Solr
Issue Type: Bug
Security Level: Public (Default Security Level. Issues are Public)
Affects Versions: 9.6.1, 9.7, 9.6, 9.4.1, 9.5, 9.4, 9.2.1, 9.3, 9.1.1, 9.2,
9.1, 9.0
Reporter: Colvin Cowie
The PUT method on the v2 collectionprop API doesn't work, because
{{org.apache.solr.handler.admin.api.CollectionProperty}} doesn't have an
@Inject annotation [on its
constructor|https://github.com/apache/solr/blob/main/solr/core/src/java/org/apache/solr/handler/admin/api/CollectionProperty.java#L41]
That leads to a 500 response and errors like this in the logs
{quote}Caused by: java.lang.NoSuchMethodException: Could not find a suitable
constructor in org.apache.solr.handler.admin.api.CollectionProperty class.
at
org.glassfish.jersey.inject.hk2.JerseyClassAnalyzer.getConstructor(JerseyClassAnalyzer.java:168)
~[?:?]
...
_The following warnings have been detected: WARNING: HK2 service reification
failed for [org.apache.solr.handler.admin.api.CollectionProperty] with an
exception:_
{quote}
I've taken a quick look through the other transport classes, and the same
problem exists for {{{}org.apache.solr.handler.admin.api.InstallCoreData{}}}.
The rest look okay, but ideally we need a smoke test for each v2 API to verify
that all services are wired in correctly. The functionality is already tested
via v1 APIs.
--
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
[jira] [Commented] (SOLR-17644) Collection creation fails when replica placement plugin and basic auth are enabled
[
https://issues.apache.org/jira/browse/SOLR-17644?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17931514#comment-17931514
]
Colvin Cowie commented on SOLR-17644:
-
Yes, it worked up until 9.7, so only 9.8 affected.
> Collection creation fails when replica placement plugin and basic auth are
> enabled
> --
>
> Key: SOLR-17644
> URL: https://issues.apache.org/jira/browse/SOLR-17644
> Project: Solr
> Issue Type: Bug
> Security Level: Public(Default Security Level. Issues are Public)
>Affects Versions: main (10.0), 9.8
>Reporter: Colvin Cowie
>Assignee: Sanjay Dutt
>Priority: Major
> Labels: pull-request-available
> Fix For: 9.8.1
>
> Time Spent: 1h 40m
> Remaining Estimate: 0h
>
> In Solr 9.8 and latest, collection creation fails when the replica placement
> plugin and authentication are both configured. See
> [https://the-asf.slack.com/archives/CEKUCUNE9/p1738152813677179] for more info
>
> Stacktrace:
> {quote}2025-01-29 11:42:40.638 WARN (OverseerThreadFactory-22-thread-1)
> [c:main_index s: r: x: t:] o.a.s.c.s.i.SolrClientNodeStateProvider could not
> get tags from node localhost:8983_solr =>
> org.apache.solr.client.solrj.impl.BaseHttpSolrClient$RemoteSolrException:
> Error from server at
> http://localhost:8983/solr/admin/metrics
> : Expected mime type in [application/octet-stream,
> application/vnd.apache.solr.javabin] but got text/html.
>
>
> Error 401 require authentication
>
> HTTP ERROR 401 require authentication
>
> URI:/solr/admin/metrics
> STATUS:401
> MESSAGE:require authentication
> SERVLET:default
>
>
>
> at
> org.apache.solr.client.solrj.impl.HttpSolrClientBase.checkContentType(HttpSolrClientBase.java:341)
> org.apache.solr.client.solrj.impl.BaseHttpSolrClient$RemoteSolrException:
> Error from server at
> http://localhost:8983/solr/admin/metrics
> : Expected mime type in [application/octet-stream,
> application/vnd.apache.solr.javabin] but got text/html.
>
>
> Error 401 require authentication
>
> HTTP ERROR 401 require authentication
>
> URI:/solr/admin/metrics
> STATUS:401
> MESSAGE:require authentication
> SERVLET:default
>
>
>
> at
> org.apache.solr.client.solrj.impl.HttpSolrClientBase.checkContentType(HttpSolrClientBase.java:341)
> ~[?:?]
> at
> org.apache.solr.client.solrj.impl.HttpSolrClientBase.processErrorsAndResponse(HttpSolrClientBase.java:227)
> ~[?:?]
> at
> org.apache.solr.client.solrj.impl.Http2SolrClient.processErrorsAndResponse(Http2SolrClient.java:621)
> ~[?:?]
> at
> org.apache.solr.client.solrj.impl.Http2SolrClient.request(Http2SolrClient.java:542)
> ~[?:?]
> at org.apache.solr.client.solrj.SolrRequest.process(SolrRequest.java:279)
> ~[?:?]
> at org.apache.solr.client.solrj.SolrRequest.process(SolrRequest.java:295)
> ~[?:?]
> at
> org.apache.solr.client.solrj.impl.Http2SolrClient.requestWithBaseUrl(Http2SolrClient.java:604)
> ~[?:?]
> at
> org.apache.solr.client.solrj.impl.SolrClientNodeStateProvider$RemoteCallCtx.invoke(SolrClientNodeStateProvider.java:292)
> ~[?:?]
> at
> org.apache.solr.client.solrj.impl.SolrClientNodeStateProvider$RemoteCallCtx.invokeWithRetry(SolrClientNodeStateProvider.java:255)
> ~[?:?]
> at
> org.apache.solr.client.solrj.impl.SolrClientNodeStateProvider.fetchReplicaMetrics(SolrClientNodeStateProvider.java:190)
> ~[?:?]
> at
> org.apache.solr.client.solrj.impl.NodeValueFetcher.getRemotePropertiesAndMetrics(NodeValueFetcher.java:125)
> ~[?:?]
> at
> org.apache.solr.client.solrj.impl.NodeValueFetcher.getTags(NodeValueFetcher.java:187)
> ~[?:?]
> at
> org.apache.solr.client.solrj.impl.SolrClientNodeStateProvider.fetchTagValues(SolrClientNodeStateProvider.java:114)
> ~[?:?]
> at
> org.apache.solr.client.solrj.impl.SolrClientNodeStateProvider.getNodeValues(SolrClientNodeStateProvider.java:106)
> ~[?:?]
> at
> org.apache.solr.cluster.placement.impl.AttributeFetcherImpl.fetchAttributes(AttributeFetcherImpl.java:149)
> ~[?:?]
> at
> org.apache.solr.cluster.placement.plugins.AffinityPlacementFactory$AffinityPlacementPlugin.getBaseWeightedNodes(AffinityPlacementFactory.java:284)
> ~[?:?]
> at
> org.apache.solr.cluster.placement.plugins.OrderedNodePlacementPlugin.getWeightedNodes(OrderedNodePlacementPlugin.java:316)
> ~[?:?]
> at
> org.apache.solr.cluster.placement.plugins.OrderedNodePlacementPlugin.computePlacements(OrderedNodePlacementPlugin.java:88)
> ~[?:?]
> at
> org.apache.solr.cluster.placement.impl.PlacementPluginAssignStrategy.assign(PlacementPluginAssignStrategy.java:84)
> ~[?:?]
> at
> org.apache.solr.cloud.api.collections.Assign$AssignStrategy.assign(Assign.java:432)
> ~[?:?]
> at
> org.apache.solr.cloud.api.collections.CreateCollectionCmd.buildReplicaPositions(CreateCollectionCmd.ja
[jira] [Created] (SOLR-17728) Create a smoke test for the v2 API
Colvin Cowie created SOLR-17728: --- Summary: Create a smoke test for the v2 API Key: SOLR-17728 URL: https://issues.apache.org/jira/browse/SOLR-17728 Project: Solr Issue Type: Test Security Level: Public (Default Security Level. Issues are Public) Components: v2 API Reporter: Colvin Cowie Currently the testing of the v2 API is mostly done by invoking v1 APIs which internally map to v2 code, so the API logic is tested. However the transport layer of the v2 API isn't covered and I've found several bugs so far. A first pass at a smoke test has started here: [https://github.com/apache/solr/pull/3023] -- 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
[jira] [Created] (SOLR-17729) Some endpoints are missing from the v2 API spec
Colvin Cowie created SOLR-17729: --- Summary: Some endpoints are missing from the v2 API spec Key: SOLR-17729 URL: https://issues.apache.org/jira/browse/SOLR-17729 Project: Solr Issue Type: Improvement Reporter: Colvin Cowie These endpoints are missing from the spec, I don't know whether any other endpoints are also missing. * GET /cluster * GET /cluster/nodes -- 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
[jira] [Created] (SOLR-17730) v2 API error handling
Colvin Cowie created SOLR-17730: --- Summary: v2 API error handling Key: SOLR-17730 URL: https://issues.apache.org/jira/browse/SOLR-17730 Project: Solr Issue Type: Improvement Reporter: Colvin Cowie Some APIs return 500s when a 400 or 404 would be more appropriate * /collections/foo returns a 500 instead of a 404 * Invalid JSON / incompatible JSON in a request body returns a 500 instead of a 400. For example, if you send an Array rather than an Object you will get a Jackson exception which turns into a 500. -- 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
[jira] [Created] (SOLR-17731) Some v2 APIs are overshadowed at runtime so can't be used
Colvin Cowie created SOLR-17731:
---
Summary: Some v2 APIs are overshadowed at runtime so can't be used
Key: SOLR-17731
URL: https://issues.apache.org/jira/browse/SOLR-17731
Project: Solr
Issue Type: Improvement
Reporter: Colvin Cowie
This sort of problem tends to happen when multiple resources declare
overlapping paths, e.g. "abc/xyz" in one resource and "abc" in another, but
there may be other reasons for it too.
These APIs exist in code but aren't accessible, you get a 405 because another
resource handler is responding.
* POST /collections/\{collectionName}/snapshots/\{snapshotName} -->
CollectionSnapshotsApi.CreateCollectionSnapshot#CreateCollectionSnapshot
* GET /aliases/\{aliasName} --> ListAliasesApi.getAliases()
--
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
[jira] [Updated] (SOLR-17731) Some v2 APIs are overshadowed at runtime so can't be used
[
https://issues.apache.org/jira/browse/SOLR-17731?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Colvin Cowie updated SOLR-17731:
Issue Type: Bug (was: Improvement)
> Some v2 APIs are overshadowed at runtime so can't be used
> -
>
> Key: SOLR-17731
> URL: https://issues.apache.org/jira/browse/SOLR-17731
> Project: Solr
> Issue Type: Bug
>Reporter: Colvin Cowie
>Priority: Major
>
> This sort of problem tends to happen when multiple resources declare
> overlapping paths, e.g. "abc/xyz" in one resource and "abc" in another, but
> there may be other reasons for it too.
> These APIs exist in code but aren't accessible, you get a 405 because another
> resource handler is responding.
> * POST /collections/\{collectionName}/snapshots/\{snapshotName} -->
> CollectionSnapshotsApi.CreateCollectionSnapshot#CreateCollectionSnapshot
> * GET /aliases/\{aliasName} --> ListAliasesApi.getAliases()
--
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
[jira] [Created] (SOLR-17733) Cluster filestore v2 API fails in cloud mode
Colvin Cowie created SOLR-17733:
---
Summary: Cluster filestore v2 API fails in cloud mode
Key: SOLR-17733
URL: https://issues.apache.org/jira/browse/SOLR-17733
Project: Solr
Issue Type: Bug
Reporter: Colvin Cowie
Calling DELETE /cluster/filestore/files/\{file} results in a 500. The
implementation of delete cluster file first calls delete local file, but that
first checks to see if the file exists in the cluster and fails if it does so.
{{10454 ERROR (qtp1073592819-60-null-5) [n:127.0.0.1:56447_solr c: s: r: x:
t:null-5] o.a.s.j.CatchAllExceptionMapper 500 Exception}}
{{ => org.apache.solr.common.SolrException:
org.apache.solr.common.SolrException: The path exists in ZK, delete and retry}}
{{ at
org.apache.solr.filestore.ClusterFileStore.doClusterDelete(ClusterFileStore.java:282)}}
{{org.apache.solr.common.SolrException: org.apache.solr.common.SolrException:
The path exists in ZK, delete and retry}}
{{ at
org.apache.solr.filestore.ClusterFileStore.doClusterDelete(ClusterFileStore.java:282)
~[main/:?]}}
{{ at
org.apache.solr.filestore.ClusterFileStore.doDelete(ClusterFileStore.java:296)
~[main/:?]}}
{{ at
org.apache.solr.filestore.ClusterFileStore.deleteFile(ClusterFileStore.java:312)
~[main/:?]}}
{{ ...}}
Also when calling POST /cluster/filestore/commands/sync/\{file} it always fails
with a 500 because the node already exists in ZooKeeper. How can this API be
used? If it isn't supported in cloud mode then it should return a 501 (not
implemented) or similar, but maybe I'm misunderstanding the intent of this API.
See V2APISmokeTest in SOLR-17728
--
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
