[
https://issues.apache.org/jira/browse/LUCENE-9670?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17269236#comment-17269236
]
Michael McCandless commented on LUCENE-9670:
--------------------------------------------
{quote}You can add {{--stacktrace}} to gradle invocation, this should help in
diagnosing the root cause of those strange errors, Mike.
{quote}
Thanks, I'll add that option to the nightly benchmark's {{precommit}}
invocation, and I'll re-beast {{precommit}} with that. Let's see if the
strange errors happen again...
{quote}> I will now 1) go back to my original ~/.gradle/gradle.properties
I don't know if this is a good idea. This overrides global defaults... are the
settings generated on the first gradle run not working for you? Perhaps we
should improve those?
{quote}
Well, first off, the "auto-properties" solution requires two {{gradle}}
invocations, right? First runs w/o good defaults but writes
{{gradle.properties}}. Second run will use those properties. After a {{git
clean -xfd}} the {{gradle.properties}} is gone.
But second off, e.g. here is the {{gradle.properties}} written on my 128 core
{{beast3}} box:
{noformat}
[mike@beast3 trunk]$ cat gradle.properties
# These settings have been generated automatically on the first run.
# See gradlew :helpLocalSettings for more information.
systemProp.file.encoding=UTF-8
org.gradle.jvmargs=-Xmx3g
org.gradle.parallel=true
org.gradle.priority=normal
org.gradle.warning.mode=none
# You may disable the background daemon if it consumes too much memory.
org.gradle.daemon=true
org.gradle.daemon.idletimeout=900000
# Maximum number of parallel gradle workers.
org.gradle.workers.max=1
# Maximum number of test JVMs forked per test task.
tests.jvms=1{noformat}
Which I don't understand – why only 1 gradle worker and 1 test JVM?
I also would like to direct test temp output to my {{tmpfs}} mount instead of
local SSD. And I keep going back and forth about whether this {{daemon}} is a
good thing or not.
Finally, if push comes to shove, I blame [~rcmuir] for suggesting these
settings defaults :) I really have not much clue what these powerful sounding
gradle settings are doing!
> gradle precommit sometimes fails with "IOException: stream closed" from
> javadoc in nightly benchmarks
> -----------------------------------------------------------------------------------------------------
>
> Key: LUCENE-9670
> URL: https://issues.apache.org/jira/browse/LUCENE-9670
> Project: Lucene - Core
> Issue Type: Bug
> Reporter: Michael McCandless
> Priority: Major
>
> I recently added tracking how long {{gradle precommit}} takes each night so
> we can track slowdowns over time.
> But it sometimes fails with:
> {noformat}
> > Task :lucene:join:renderJavadoc FAILED
> Could not read standard output of command '/opt/jdk-15.0.1/bin/javadoc'.
> java.io.IOException: Stream Closed
> at java.base/java.io.FileOutputStream.writeBytes(Native Method)
> at java.base/java.io.FileOutputStream.write(FileOutputStream.java:347)
> at
> java.base/java.io.BufferedOutputStream.flushBuffer(BufferedOutputStream.java:81)
> at
> java.base/java.io.BufferedOutputStream.flush(BufferedOutputStream.java:142)
> at
> org.gradle.process.internal.streams.ExecOutputHandleRunner.forwardContent(ExecOutputHandleRunner.java:68)
> at
> org.gradle.process.internal.streams.ExecOutputHandleRunner.run(ExecOutputHandleRunner.java:53)
> at
> org.gradle.internal.operations.CurrentBuildOperationPreservingRunnable.run(CurrentBuildOperationPreservingRunnable.java:42)
> at
> org.gradle.internal.concurrent.ExecutorPolicy$CatchAndRecordFailures.onExecute(ExecutorPolicy.java:64)
> at
> org.gradle.internal.concurrent.ManagedExecutorImpl$1.run(ManagedExecutorImpl.java:48)
> at
> java.base/java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1130)
> at
> java.base/java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:630)
> at
> org.gradle.internal.concurrent.ThreadFactoryImpl$ManagedThreadRunnable.run(ThreadFactoryImpl.java:56)
> at java.base/java.lang.Thread.run(Thread.java:832) {noformat}
> I'm not sure why ... when I run {{./gradlew precommit}} interactively it
> doesn't seem to do this.
> The nightly tool is quite simple – it just launches a sub-process using
> {{os.system}}: (first to {{git clean}} then to run {{./gradlew precommit)}}:
> https://github.com/mikemccand/luceneutil/blob/master/src/python/runNightlyGradleTestPrecommit.py
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]