[jira] Closed: (WAGONSSH-36) SSH transport hangs on large transfers
[ http://jira.codehaus.org/browse/WAGONSSH-36?page=all ] John Casey closed WAGONSSH-36: -- Resolution: Fixed fixed. Implemented proposed modification to the unzip command line. > SSH transport hangs on large transfers > -- > > Key: WAGONSSH-36 > URL: http://jira.codehaus.org/browse/WAGONSSH-36 > Project: wagon-ssh > Type: Bug > Versions: 1.0-alpha-6 > Reporter: Mike Perham > Assignee: John Casey > Fix For: 1.0-alpha-7 > > > (1.0-alpha-6 needs to be released and a7 added as a new version) > executeCommand( "cd " + path + "; unzip -o " + zipFile.getName() > + "; rm -f " + zipFile.getName() ); > This code hangs when the zip is large. The problem is that the process's > outputstream is not read so eventually it fills its buffer and the process > hangs. My fix? Add "-q" to unzip's arguments so that it does not spew tons > of output. -- 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]
[jira] Commented: (WAGONSSH-41) CLONED FOR CODE REVISION -SSH transport hangs on large transfers
[ http://jira.codehaus.org/browse/WAGONSSH-41?page=comments#action_59570 ] John Casey commented on WAGONSSH-41: This has been cloned to remind me to revisit this piece of code, and try to incorporate a better fix, where the output stream is read (and dumped?)...this should be a cleaner long-term fix, I believe. However, due to the elevated risk involved with that revision, I'm waiting until after the 1.0-alpha-7 release to do it. > CLONED FOR CODE REVISION -SSH transport hangs on large transfers > > > Key: WAGONSSH-41 > URL: http://jira.codehaus.org/browse/WAGONSSH-41 > Project: wagon-ssh > Type: Bug > Versions: 1.0-alpha-6 > Reporter: John Casey > Assignee: John Casey > > > (1.0-alpha-6 needs to be released and a7 added as a new version) > executeCommand( "cd " + path + "; unzip -o " + zipFile.getName() > + "; rm -f " + zipFile.getName() ); > This code hangs when the zip is large. The problem is that the process's > outputstream is not read so eventually it fills its buffer and the process > hangs. My fix? Add "-q" to unzip's arguments so that it does not spew tons > of output. -- 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]
[jira] Updated: (WAGONSSH-41) CLONED FOR CODE REVISION -SSH transport hangs on large transfers
[ http://jira.codehaus.org/browse/WAGONSSH-41?page=all ] John Casey updated WAGONSSH-41: --- Fix Version: (was: 1.0-alpha-7) > CLONED FOR CODE REVISION -SSH transport hangs on large transfers > > > Key: WAGONSSH-41 > URL: http://jira.codehaus.org/browse/WAGONSSH-41 > Project: wagon-ssh > Type: Bug > Versions: 1.0-alpha-6 > Reporter: John Casey > Assignee: John Casey > > > (1.0-alpha-6 needs to be released and a7 added as a new version) > executeCommand( "cd " + path + "; unzip -o " + zipFile.getName() > + "; rm -f " + zipFile.getName() ); > This code hangs when the zip is large. The problem is that the process's > outputstream is not read so eventually it fills its buffer and the process > hangs. My fix? Add "-q" to unzip's arguments so that it does not spew tons > of output. -- 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]
[jira] Created: (WAGONSSH-41) CLONED FOR CODE REVISION -SSH transport hangs on large transfers
CLONED FOR CODE REVISION -SSH transport hangs on large transfers Key: WAGONSSH-41 URL: http://jira.codehaus.org/browse/WAGONSSH-41 Project: wagon-ssh Type: Bug Versions: 1.0-alpha-6 Reporter: John Casey Assigned to: John Casey Fix For: 1.0-alpha-7 (1.0-alpha-6 needs to be released and a7 added as a new version) executeCommand( "cd " + path + "; unzip -o " + zipFile.getName() + "; rm -f " + zipFile.getName() ); This code hangs when the zip is large. The problem is that the process's outputstream is not read so eventually it fills its buffer and the process hangs. My fix? Add "-q" to unzip's arguments so that it does not spew tons of output. -- 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]
[jira] Closed: (WAGONSSH-40) sftp:// repository crashes build on failed download
[ http://jira.codehaus.org/browse/WAGONSSH-40?page=all ] John Casey closed WAGONSSH-40: -- Resolution: Fixed Fix Version: 1.0-alpha-7 fixed to catch the exception when trying to CD into a non-existent directory in getIfNewer(..), and throw a ResourceDoesNotExistException, rather than a TransferFailedException in these cases. If the resource's directory doesn't exist, it's not a transport problem, but a problem of the resource not being on that repository. > sftp:// repository crashes build on failed download > --- > > Key: WAGONSSH-40 > URL: http://jira.codehaus.org/browse/WAGONSSH-40 > Project: wagon-ssh > Type: Bug > Versions: 1.0-alpha-6 > Reporter: Stephen Duncan Jr > Assignee: John Casey > Fix For: 1.0-alpha-7 > > > When using sftp:// for an internal repository, when a download fails, > an error is thrown, and the build quits, even though the file is a) > available in the central repository, or b) optional (downloaidng > sources using Eclipse plugin). Previously, when using scp with > another machine, this never happened. > Here's the error on downloading: > $ mvn install > [INFO] Scanning for projects... > [INFO] > > [INFO] Building Trouble Tickets Portlet > [INFO]task-segment: [install] > [INFO] > > [INFO] [resources:resources] > [INFO] Using default encoding to copy filtered resources. > Downloading: > sftp://cdciecm.je.jfcom.mil/var/www/maven2/org/springframework/spring-core/1.2.6/spring-core-1.2.6.pom > No such file >at com.jcraft.jsch.ChannelSftp.throwStatusError(Unknown Source) >at com.jcraft.jsch.ChannelSftp.cd(Unknown Source) >at > org.apache.maven.wagon.providers.ssh.SftpWagon.getIfNewer(SftpWagon.java:275) >at > org.apache.maven.wagon.providers.ssh.SftpWagon.get(SftpWagon.java:335) >at > org.apache.maven.artifact.manager.DefaultWagonManager.getRemoteFile(DefaultWagonManager.java:369) >at > org.apache.maven.artifact.manager.DefaultWagonManager.getArtifact(DefaultWagonManager.java:282) >at > org.apache.maven.artifact.manager.DefaultWagonManager.getArtifact(DefaultWagonManager.java:244) >at > org.apache.maven.artifact.resolver.DefaultArtifactResolver.resolve(DefaultArtifactResolver.java:124) >at > org.apache.maven.artifact.resolver.DefaultArtifactResolver.resolve(DefaultArtifactResolver.java:63) >at > org.apache.maven.project.DefaultMavenProjectBuilder.findModelFromRepository(DefaultMavenProjectBuilder.java:3 > 86) >at > org.apache.maven.project.DefaultMavenProjectBuilder.buildFromRepository(DefaultMavenProjectBuilder.java:351) >at > org.apache.maven.project.artifact.MavenMetadataSource.retrieve(MavenMetadataSource.java:102) >at > org.apache.maven.artifact.resolver.DefaultArtifactCollector.recurse(DefaultArtifactCollector.java:282) >at > org.apache.maven.artifact.resolver.DefaultArtifactCollector.recurse(DefaultArtifactCollector.java:309) >at > org.apache.maven.artifact.resolver.DefaultArtifactCollector.collect(DefaultArtifactCollector.java:67) >at > org.apache.maven.artifact.resolver.DefaultArtifactResolver.resolveTransitively(DefaultArtifactResolver.java:2 > 23) >at > org.apache.maven.artifact.resolver.DefaultArtifactResolver.resolveTransitively(DefaultArtifactResolver.java:2 > 11) >at > org.apache.maven.artifact.resolver.DefaultArtifactResolver.resolveTransitively(DefaultArtifactResolver.java:1 > 82) >at > org.apache.maven.plugin.DefaultPluginManager.resolveTransitiveDependencies(DefaultPluginManager.java:1120) >at > org.apache.maven.plugin.DefaultPluginManager.executeMojo(DefaultPluginManager.java:369) >at > org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoals(DefaultLifecycleExecutor.java:531) >at > org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoalWithLifecycle(DefaultLifecycleExecutor.java:47 > 2) >at > org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoal(DefaultLifecycleExecutor.java:451) >at > org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoalAndHandleFailures(DefaultLifecycleExecutor.jav > a:303) >at > org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeTaskSegments(DefaultLifecycleExecutor.java:270) >at > org.apache.maven.lifecycle.DefaultLifecycleExecutor.execute(DefaultLifecycleExecutor.java:139) >at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:322) >at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:115) >at org.apache.maven.cli.MavenCli.main(MavenCli.java:249) >at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) >at
