[JIRA] (JENKINS-7114) aborting download of workspace files makes slave agent hang

[scm_issue_l...@java.net (JIRA)]

SCM/JIRA link daemon commented on JENKINS-7114 aborting download of workspace files makes slave agent hang Code changed in jenkins User: Kohsuke Kawaguchi Path: src/main/java/hudson/remoting/Capability.java src/main/java/hudson/remoting/Channel.java src/main/java/hudson/remoting/Command.java src/main/java/hudson/remoting/MimicException.java src/main/java/hudson/remoting/ProxyOutputStream.java src/test/java/hudson/remoting/DeadRemoteOutputStreamTest.java http://jenkins-ci.org/commit/remoting/d084f5095f11a8bcb80913266d664b9d1f17dc3b Log: [FIXED JENKINS-7114] fixed the layer confusion in the remoting When ProxyOutputStream sends write(byte[]) to the other end and the actual write fails, "NotifyDeadWriter" object comes back and reports back that the write has failed. Without this mechanism, the writer side will keep on going. Because the RemoteOutputStream service is a lower layer service that cannot rely on custom classloading service (doing so would create cyclic dependencies), when we send back this exception, the object graph of the exception needs to be deserializable on the receiver side. This is not the case when the exception class is defined by the user (as is the case of winstone.ClientSocketException.) This fix addresses this problem by turning an exception class into another class that emulates the output of the original exception. To make this change interopeable with earlier versions, we need to introduce a new capability flag. If we send MimicException to the other side and the other side doesn't have this class definition, then it'll cause automatic fail. Compare: https://github.com/jenkinsci/remoting/compare/2b1ec8ab1528...d084f5095f11

This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators. For more information on JIRA, see: http://www.atlassian.com/software/jira