[ http://jira.codehaus.org/browse/MNG-678?page=comments#action_47483 ]
Ørjan Austvold commented on MNG-678: ------------------------------------ I have done some tracing on this error and come to the conclusion that the intermittent failure is caused by a race condition (and a bug in jsch). Upon file download/upload ScpWagon terminates the jsch Channel based on expected number of bytes successfully read/written. This in turn nullifies the io attribute of the channel. Now, if the internal thread of the jsch Sesson receives an SSH_MSG_CHANNEL_EOF from the ssh server and manages to fetch the Channel object before it is terminated by ScpWagon, it will simply crash on an NPE within the eof_remote() method of the Channel. This will mark the Session as disconnected, and the session thread dies. The effect of this is that the _next_ time ScpWagon tries to use Session, jsch reports that it's down. In my opinion this is a lack of good design in jsch. It should _not_ allow multiple thread to operate on a channel object at the same time. A simple synchronized checkout/check in scheme should do the trick. I noticed on the mailing list of jsch that there's an jsch 0.1.22-rc8 out there, but the issue have not been fixed in this version. I filed a bug at the sourceforge project for jsch. http://sourceforge.net/tracker/index.php?func=detail&aid=1308660&group_id=64920&atid=509122 While we're waiting for a fix in jsch, I guess that ScpWagon should test for if a session is connected before trying to create a channel. There could be other reasons for a session getting disconnected. If a session has been disconnected ScpWagon could try to connect once more and bail out if that fails. Thanks, Ørjan > scp intermittently failing deploying artifact > --------------------------------------------- > > Key: MNG-678 > URL: http://jira.codehaus.org/browse/MNG-678 > Project: Maven 2 > Type: Bug > Components: maven-artifact > Versions: 2.0-alpha-3 > Environment: JDK 1.5, Red Hat 9 > Reporter: Joe Futrelle > Assignee: Brett Porter > Fix For: 2.0-beta-3 > > > Some of the time, deploying artifacts fails during the scp transfer. The > bottom of the stack trace is reproduced below. If I run the m2 deploy enough > times, it succeeds; not sure why. > This is not an unknown issue with Jsch; apparently client code can cause > behavior like this if it doesn't dispose of connections properly. Possibly a > plugin that's runs before the deploy phase is messing up the connection state > somehow? > Caused by: org.apache.maven.wagon.TransferFailedException: Error occured > while deploying 'ncsa/gsbt/1.0-SNAPSHOT/gsbt-1.0-20050728.190330-38.pom.sha1' > to remote repository: scp://chasm.ncsa.uiuc.edu//home/futrelle/m2/repository > at > org.apache.maven.wagon.providers.ssh.ScpWagon.put(ScpWagon.java:331) > at > org.apache.maven.artifact.manager.DefaultWagonManager.putRemoteFile(DefaultWagonManager.java:167) > at > org.apache.maven.artifact.manager.DefaultWagonManager.putArtifact(DefaultWagonManager.java:91) > at > org.apache.maven.artifact.deployer.DefaultArtifactDeployer.deploy(DefaultArtifactDeployer.java:73) > ... 17 more > Caused by: com.jcraft.jsch.JSchException: session is down > at com.jcraft.jsch.Channel.connect(Unknown Source) > at > org.apache.maven.wagon.providers.ssh.ScpWagon.put(ScpWagon.java:271) > ... 20 more -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
