-
Bug
-
Resolution: Fixed
-
Critical
-
None
If a stream is open remotely using FilePath.read() and the file is not read to the very end, the log will be spammed with exceptions like:
Jan 10, 2011 1:36:51 PM hudson.remoting.ProxyOutputStream$Chunk$1 run WARNING: Failed to write to stream java.io.IOException: Pipe is already closed at hudson.remoting.FastPipedOutputStream.write(FastPipedOutputStream.java:147) at hudson.remoting.FastPipedOutputStream.write(FastPipedOutputStream.java:131) at hudson.remoting.ProxyOutputStream$Chunk$1.run(ProxyOutputStream.java:185)
...and finally disconnect the slave. Several plug-ins are affected by this bug, for instance the Emma-plug-in. Marked as critical since it yet another remote issue and keeps us from upgrade. It is also easy to reproduce.
To reproduce, just create a publisher plug-in with a perform() that looks like this:
@Override public boolean perform(AbstractBuild build, Launcher launcher, BuildListener listener) throws IOException { InputStream in = build.getWorkspace().child("large_file_in_workspace").read(); // Just read one byte System.out.println(in.read()); // Close it and watch the hudson log grow and slave (most often) disconnect. in.close(); return true; }
Test the plug-in with Hudson 1.390+. Make sure the new publisher plug-in is used in a project running on a slave (and also make sure that the "large_file_in_workspace"-file exists in the remote workspace).
Hi! I'm really glad that someone decides to tackle this one. So thanks for jumping on it. Really bad remoting issues have been plaguing Hudson since 20 releases back.
Great too see that you can get a first fix out this quickly. It will most certainly make the IOExceptions (and the remote disconnects) go away for the publisher plug-ins affected by this issue.
But still. Hudson do need a mechanism to allow the receiver to notify the sender that it should stop pushing stream data. I myself were in a situation were I tried to read a header of a huge artifact. Pushing the full file would not really work in this situation. (Of course it is possible to work around the issue in the plug-in code, but the main issue will still be lingering in the Hudson core).
I have spent some time thinking about how this should be done by the remoting library, without the need for a larger refactoring, but have not come up with a decent solution. So I'm more than glad that you are prepared to tackle it.