[ 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: issues-unsubscr...@lucene.apache.org For additional commands, e-mail: issues-h...@lucene.apache.org