[jira] [Comment Edited] (SOLR-16634) "gradlew check" fails with OOM on fresh clone

["Ishan Chattopadhyaya (Jira)" <ji...@apache.org>]

    [ https://issues.apache.org/jira/browse/SOLR-16634?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17680262#comment-17680262 ] 

Ishan Chattopadhyaya edited comment on SOLR-16634 at 1/24/23 3:31 PM:
----------------------------------------------------------------------

On a reasonably modern machine, the defaults should be good enough to run "gradlew check" on a fresh clone without needing any special commands. It should work on first run, without needing to run "gradlew localSettings" a second time. And if it fails the first time on a reasonable hardware configuration, then why shouldn't we document that one needs to run "gradlew localSettings" upfront before proceeding, such that users don't have to encounter a failure, then read an "IMPORTANT" message (that appears much earlier than the failure) and then copy paste a command from there ("gradle helpLocalSettings"), run it (and read 2 pages of text), and then figure out that they need to run "gradlew localSettings" in order to proceed.

bq. IMPORTANT. This is the first time you ran the build. I wrote some sane defaults (for this machine) to 'gradle.properties', they will be picked up on consecutive gradle invocations (not this one).
Also, the "IMPORTANT" message should perhaps be a WARNING, and also should be better worded. The word "consecutive" should be replaced with "subsequent", to make it meaningful.

bq. Since you are apparently in capable of reading the logs that you have posted twice now.
Anyway, I don't have patience to work through this anymore with such personal hostility. I have better things to do.


was (Author: ichattopadhyaya):
On a reasonably modern machine, the defaults should be good enough to run "gradlew check" without needing any special commands. It should work on first run, without needing to run "gradlew localSettings" a second time. And if it fails the first time on a reasonable hardware configuration, then why shouldn't we document that one needs to run "gradlew localSettings" upfront before proceeding, such that users don't have to encounter a failure, then read an "IMPORTANT" message (that appears much earlier than the failure) and then copy paste a command from there ("gradle helpLocalSettings"), run it (and read 2 pages of text), and then figure out that they need to run "gradlew localSettings" in order to proceed.

bq. IMPORTANT. This is the first time you ran the build. I wrote some sane defaults (for this machine) to 'gradle.properties', they will be picked up on consecutive gradle invocations (not this one).
Also, the "IMPORTANT" message should perhaps be a WARNING, and also should be better worded. The word "consecutive" should be replaced with "subsequent", to make it meaningful.

bq. Since you are apparently in capable of reading the logs that you have posted twice now.
Anyway, I don't have patience to work through this anymore with such personal hostility. I have better things to do.

> "gradlew check" fails with OOM on fresh clone
> ---------------------------------------------
>
>                 Key: SOLR-16634
>                 URL: https://issues.apache.org/jira/browse/SOLR-16634
>             Project: Solr
>          Issue Type: Bug
>      Security Level: Public(Default Security Level. Issues are Public) 
>            Reporter: Ishan Chattopadhyaya
>            Priority: Major
>
> I have a 64GB machine, where a fresh Solr clone was done. "gradlew check" failed with this following:
> https://issues.apache.org/jira/browse/SOLR-15616?focusedCommentId=17679832&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-17679832
> {code}
> [ishan@7980xe solr] $ ./gradlew check -x test -Pvalidation.errorprone=true
> 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 
> > Task :localSettings
> IMPORTANT. This is the first time you ran the build. I wrote some sane defaults (for this machine) to 'gradle.properties', they will be picked up on consecutive gradle invocations (not this one).
> Run gradlew :helpLocalSettings for more information.
> > Task :rat
> Trying to override old definition of task javadoc
> > Task :solr:solrj:compileJava
> Note: Some input files use or override a deprecated API.
> Note: Recompile with -Xlint:deprecation for details.
> > Task :solr:solrj-streaming:compileJava
> Note: Some input files use or override a deprecated API.
> Note: Recompile with -Xlint:deprecation for details.
> > Task :solr:solrj-zookeeper:compileJava
> Note: Some input files use or override a deprecated API.
> Note: Recompile with -Xlint:deprecation for details.
> FAILURE: Build failed with an exception.
> * What went wrong:
> Gradle build daemon has been stopped: JVM garbage collector thrashing and after running out of JVM memory
> * Try:
> > Run with --stacktrace option to get the stack trace.
> > Run with --info or --debug option to get more log output.
> > Run with --scan to get full insights.
> * Get more help at https://help.gradle.org
> {code}
> For context, [~krisden] has attributed this to user error: https://issues.apache.org/jira/browse/SOLR-15616?focusedCommentId=17679837&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-17679837
> Please also note that "gradlew localSettings" also resulted in a subsequent OOM failure (details here: https://issues.apache.org/jira/browse/SOLR-15616?focusedCommentId=17679841&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-17679841)



--
This message was sent by Atlassian Jira
(v8.20.10#820010)

---------------------------------------------------------------------
To unsubscribe, e-mail: issues-unsubscribe@solr.apache.org
For additional commands, e-mail: issues-help@solr.apache.org