Running TwoMinuteExample: Socket Exception at: [Broken pipe (Write failed)]

[frankgerhardt]

Debian 8, OpenJDK 8, fitnesse-standalone.jar, fitnesse-git-plugin-1.2.0-all.jar.

Firefox ESR

Version=v20190216

Fresh install.

When running the TwoMinuteExample test, I get this Exception about every third time. The test results are displayed ok.

WARNING: Socket Exception at: 1550448365328 [Broken pipe (Write failed)]
java.net.SocketException: Broken pipe (Write failed)
	at java.base/java.net.SocketOutputStream.socketWrite0(Native Method)
	at java.base/java.net.SocketOutputStream.socketWrite(SocketOutputStream.java:110)
	at java.base/java.net.SocketOutputStream.write(SocketOutputStream.java:138)
	at fitnesse.FitNesseExpediter.send(FitNesseExpediter.java:63)
	at fitnesse.http.ChunkedResponse.closeTrailer(ChunkedResponse.java:75)
	at fitnesse.http.ChunkedResponse.close(ChunkedResponse.java:82)
	at fitnesse.responders.run.SuiteResponder.closeHtmlResponse(SuiteResponder.java:341)
	at fitnesse.responders.run.SuiteResponder.doSending(SuiteResponder.java:104)
	at fitnesse.responders.ChunkingResponder.startSending(ChunkingResponder.java:74)
	at fitnesse.http.ChunkedResponse.sendTo(ChunkedResponse.java:27)
	at fitnesse.FitNesseExpediter.sendResponse(FitNesseExpediter.java:86)
	at fitnesse.FitNesseExpediter.run(FitNesseExpediter.java:52)
	at java.base/java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:515)
	at java.base/java.util.concurrent.FutureTask.run(FutureTask.java:264)
	at java.base/java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1128)
	at java.base/java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:628)
	at java.base/java.lang.Thread.run(Thread.java:834)

I'd prefer not to get these Exceptions even if they are only "warnings".

[tcnh]

Did a bit of digging on this one. Couldn't reproduce it on a windows rig, but a debian VM with the mentioned Java version gave the described behaviour.

What I >think< happens is that SuiteResponder calls closeTrailer() and then close() on the respnse object.
close() then also calls closeTrailer(), resulting in CR/LF being sent twice in a row. My guess is that the first call causes the socket connection to be dropped, sometimes in time for the second call to actually fail (as if the test was stopped manually).

I removed the -what seems to be- obsolete call from SuiteResponder in my 1187 branch. After that, I can no longer reproduce the issues (and see no new trouble appearing on both windows and debian jessie when running the two-minute Example and the full SuiteAcceptanceTests)

[frankgerhardt]

I had this only in Firefox, not in Chrome.

[dfurmans]

I had this only in Firefox, not in Chrome.

That is the same with me! On Debian 10 (JVM 11) and Firefox after 10 second the socket is closing and the response can not be fulfill - because the browser is not waiting for it. However under the hood all works perfectly.