[
https://issues.apache.org/jira/browse/SOLR-16634?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17680289#comment-17680289
]
Kevin Risden commented on SOLR-16634:
-------------------------------------
{quote} Why not just stick to the substance of the problem I've described and
only focus on constructive solutions?{quote}
wow.... I did I put aside the differences and contributed to trying to move
things forward. Multiple times on SOLR-15616 AND here:
https://issues.apache.org/jira/browse/SOLR-16634?focusedCommentId=17680012&page=com.atlassian.jira.plugin.system.issuetabpanels%3Acomment-tabpanel#comment-17680012
{quote}
* What went wrong:
Execution failed for task ':solr:core:forbiddenApisMain'.
> GC overhead limit exceeded
This is unexpected (and not something I've seen before). Again the
localSettings help explains that you MIGHT have to tweak gradle.properties
based on your hardware. If you followed that recommendation you might have
looked at gradle.properties and seen if maybe the 1G is too low on your
hardware. It might be worth looking at raising the 1G in gradle.properties but
without knowing why your machine is doing what it is doing. It wouldn't make
sense to globally make that change.{quote}
I pointed out the EXACT same thing in the first comment on SOLR-15616 when you
said you had memory issues -
https://issues.apache.org/jira/browse/SOLR-15616?focusedCommentId=17679824&page=com.atlassian.jira.plugin.system.issuetabpanels%3Acomment-tabpanel#comment-17679824
----
For the history of personal attacks - you started this [~ichattopadhyaya] with
two comments on SOLR-15616 that were uncalled for and unnecessary.
You started the personal attacks here:
https://issues.apache.org/jira/browse/SOLR-15616?focusedCommentId=17679847&page=com.atlassian.jira.plugin.system.issuetabpanels%3Acomment-tabpanel#comment-17679847
"That is a ridiculous statement right there" - when it was a factual statement
that you responded to about removing gradle.properties and not reading the
message I had quoted. You also then doubled down with:
https://issues.apache.org/jira/browse/SOLR-15616?focusedCommentId=17679862&page=com.atlassian.jira.plugin.system.issuetabpanels%3Acomment-tabpanel#comment-17679862
"I pointed out a problem with our build, and it triggered you into accusing me
of causing that problem. :-D I apologize for breaking the build with the first
commit, but the problem I pointed out with the Solr build with a fresh clone is
a real one, that shouldn't be missed amidst your angry outbursts."
I pointed out that removing gradle.properties will break the build and
explained why. Your actions of git clean -fdx (fwiw the x is the issue since
gradle.properties is actually in the .gitignore to not be removed) - caused the
removal of build.properties and therefore the build to fail. There was no
"angry outbursts" they were messages to help move things along but you
continued again with your personal attacks.
----
Finally for the "proof" that you want - again you took your own statement out
of context - specifically:
"There is no such message. I am not sure if you're even reading the same things
as I am. I regret the time you wasted."
I pointed out the local settings part - 6 times:
*
https://issues.apache.org/jira/browse/SOLR-15616?focusedCommentId=17679824&page=com.atlassian.jira.plugin.system.issuetabpanels%3Acomment-tabpanel#comment-17679824
*
https://issues.apache.org/jira/browse/SOLR-15616?focusedCommentId=17679827&page=com.atlassian.jira.plugin.system.issuetabpanels%3Acomment-tabpanel#comment-17679827
*
https://issues.apache.org/jira/browse/SOLR-15616?focusedCommentId=17679837&page=com.atlassian.jira.plugin.system.issuetabpanels%3Acomment-tabpanel#comment-17679837
*
https://issues.apache.org/jira/browse/SOLR-15616?focusedCommentId=17679852&page=com.atlassian.jira.plugin.system.issuetabpanels%3Acomment-tabpanel#comment-17679852
*
https://issues.apache.org/jira/browse/SOLR-16634?focusedCommentId=17680012&page=com.atlassian.jira.plugin.system.issuetabpanels%3Acomment-tabpanel#comment-17680012
It is literally in the description of this jira SOLR-16634 front and center
including the two comments on SOLR-15616. The message is pretty clear:
{code:java}
> 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.
{code}
This part *they will be picked up on consecutive gradle invocations (not this
one).* explicitly saying not this invocation. Meaning the next ones will pick
up the settings needed. If you are confused on the wording - then wait the next
line says "Run gradlew :helpLocalSettings for more information." - again this
explains why this is necessary. And if you read what that says:
https://github.com/apache/solr/blob/main/help/localSettings.txt
{quote}The first invocation of any task in Solr gradle build will generate and
save a project-local 'gradle.properties' file. This file contains the defaults
you may (but don't have to) tweak for your particular hardware (or taste). Note
there are certain settings in that file that may be _required_ at runtime for
certain plugins (an example is the spotless/ google java format plugin, which
requires adding custom exports to JVM modules). Gradle build only generates
this file if it's not already present (it never overwrites the defaults) --
occasionally you may have to manually delete (or move) this file and regenerate
from scratch.{quote}
This is in the first paragraph - not the "pages" of documentation that you
think exist. With the highlight being:
{quote}Note there are certain settings in that file that may be _required_ at
runtime{quote}
And there it is - the required portion. If you didn't run out of heap you would
have run into issues with spotless and exports not being exposed by gradle by
default. Could this be up front in the first message - sure - but the messages
in the build lead to the same conclusion. That without gradle.properties (with
localSettings being one way to generate it) the build will fail 100% of the
time.
----
I have never said anything about not improving the situation. I went out of my
way to provide inputs to try to debug the issue and figure out the problem. I
have pointed out what is most likely the issue you are running into - the 1g
default heap. [~magibney] chimed in about making this configurable potentially
if needed. You went and closed the jira when you ignored all the help others
were giving and chose to deviate from the problem at hand.
> "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: [email protected]
For additional commands, e-mail: [email protected]
