[
https://issues.apache.org/jira/browse/SOLR-16634?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17680344#comment-17680344
]
Kevin Risden commented on SOLR-16634:
-------------------------------------
if looking for why things are the way they are today with localSettings
generating gradle.properties, start with this email thread for the gradle
conversion specifically look at "gradle.properties" mentions since its not
called localSettings at this point -
https://lists.apache.org/thread/mqxxjnovorg7633sdcqw2bppo0yh5p0d. The thread
jumps all over but talks about the alternatives and ends up with the generating
gradle.properties as a decent step forward including pitfalls of why.
https://lists.apache.org/thread/phhzjvvt8w8bk222xx6nzvvgo8z9ltn9 has some more
info about localSettings and why its needed to be run first for CI machines.
and finally https://lists.apache.org/thread/69d2g0blsrf0jpcxx4lj5d39hkdoyxzr
which I think is the most recent discussion about this. There is talk there
about hard failing if gradle.properties doesn't exist and isn't generated, but
at the time it was decided to not move forward with that option.
----
The tl;dr is the history behind this is there needs to be SOMETHING that
affects the gradle build and the option chosen so far is generate on first use.
This affects the next gradle daemon but at least in general this works.
gradle.properties is not regenerated everytime since you can customize for your
machine if needed. You can call gradlew localSettings up front to generate this
for you or just the second build succeeds.
The options that were looked at as far as I can tell were:
* gradle.properties checked into the project - everyone would have the same
defaults. not easily customizable per user or per machine. This ends up
hardcoded for number of jvms and other settings.
* hard stop the build if gradle.properties isn't there - this forces either the
user to restart the build again with some explanation why or say go run this
command first and then run again
* I can see the benefits to this (ease of first use) and also the downsides
(forcing user to go do something else first anyway).
* leave the gradle.properties generated at first use with the warning that is
printed and try to improve the message
This then I think poses the question of what about removing gradle.properties
today which means leave most gradle stuff as default. There are a few things
that I think are in the way but possibly surmountable:
* The biggest factor is JDK version and Gradle version for exporting certain
modules. I know recent Gradle versions have improved what needs to get exported
so its possible the export stuff can be cleaned up. Gradle plugins like
errorprone/spotless have made improvements here as well.
* The heap 1g for Gradle (which is 512MB by default) and how it causes issues
with less than 1G for most machines. Previously the heap was set to 3G which is
every single Gradle tasks that gets spun up - this is a big much and changed in
f25d77a45c53db09742cb0f9599ee7c9774b87ab. This was lowered due to a combination
of not seeing issues with heap anymore and Gradle/plugin improvements I'm
assuming that improved gradle heap usage. I don't know if its possible to go to
the default of 512MB.
* tests.jvms and workers.max are dynamically set today - not sure its possible
to set these without gradle.properties overrides and do it programmatically
* misc gradle configs (daemon, warning mode, parallel, priority, etc) that are
set in gradle.properties
So I think those are what is in the way of making a regular check out just work
without either explicitly running `./gradlew localSettings` once or running
gradle twice to have the first time generate gradle.properties with the warning.
> "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-unsubscr...@solr.apache.org
For additional commands, e-mail: issues-h...@solr.apache.org
