JSch - inputstream is closed

[filth]

Hallo,

ich verwende die JSch Bibliothek um Dateien zu einem Server zu übertragen.
Einer der User hatte am Wochenende wohl ein Problem. Die Exception in der Log sagt folgendes:

Date: Sun Mar 13 09:23:20 CET 2011
You crashed thread Thread-209
Exception was: 4: java.io.IOException: inputstream is closed
Trace: --> at com.jcraft.jsch.ChannelSftp._put(ChannelSftp.java:577)--> 
at com.jcraft.jsch.ChannelSftp.put(ChannelSftp.java:388)--> 
at nClient.Ftp.SSHUploadClient.upload(SSHUploadClient.java:149)--> 
at nClient.Packupload.PictureUpload.uploadPremiums(PictureUpload.java:204)--> 
at nClient.Packupload.PictureUpload.doUpload(PictureUpload.java:163)--> 
at nClient.Packupload.PackUploader.uploadPics(PackUploader.java:189)--> 
at nClient.Controller$2.run(Controller.java:596)
Additional Info:  OS: Windows 7 |

Die SSHUploadClient-Klasse sieht folgendermaßen aus:

	public void upload( String remoteFile, String localFile) 
	{
		checkConnection();
		
		SftpProgressMonitor monitor = new SSHProgressMonitor(myController);
		int mode=ChannelSftp.OVERWRITE;
				
		try {
			channel.put(remoteFile, localFile, monitor, mode);
		} catch (SftpException e) {
			CustomExceptionHandler myEx = new CustomExceptionHandler();
			myEx.logError(e);
		}
	}

Ich kann nicht wirklich was mit dem Fehler anfangen - jemand eine Idee? Wurde während der Übetragung die Verbindung serverseitig geschlossen?

Danke

 

[areafo]

Ja der Stream zum Server wurde geschlossen. Von wem steht da nicht. Firewall Router Sync Server usw könnte überall geschlossen wurden seien.

 

[filth]

Wie kann man sowas abfangen? In der checkConnection() prüfe ich ob der Stream bzw die Connection noch da ist, aber scheinbar reicht es in Einzelfällen nicht aus

 

[areafo]

Ja. Ein Abbruch kann auch während des Bestehens der Connection passieren?

 

[filth]

Sollte das in etwa so aussehen?

    public void upload( String remoteFile, String localFile) 
    {
        checkConnection();
        
        SftpProgressMonitor monitor = new SSHProgressMonitor(myController);
        int mode=ChannelSftp.OVERWRITE;
                
        try {
            channel.put(remoteFile, localFile, monitor, mode);
        } catch (Exception e) {
            		if(e.equals(new java.io.IOException()))
			{
				// CODE
			}
        }


    }

 

[Murray]

Die Fallunterscheidung bei den Exceptions a) ist Quatsch und b) wird nicht funktionieren.

Besser:

try {
 /* ... */
} catch (IOException iox) { //--- nur IOExceptions fangen, dann spart man sich auch die Fallunterscheidung
}

Oder - wenn man denn wirklich auch andere Exceptions fangen muss - z.B. so

try {
 /* ... */
} catch (IOException iox) { 
  /* spezifische Behandlung der IOException */
} catch (NumberFormatException nfx) { 
  /* spezifische Behandlung der NumberFormatException */
}

 

[areafo]

Ist serverseitig was zu erkennen das er den Upload beginnt und dann abbricht? Ansonsten beim abfangen der Exception gleich nen neuen Uploadversuch.

 

[filth]

Die Fallunterscheidung bei den Exceptions a) ist Quatsch und b) wird nicht funktionieren.

Besser:

try {
 /* ... */
} catch (IOException iox) { //--- nur IOExceptions fangen, dann spart man sich auch die Fallunterscheidung
}

Oder - wenn man denn wirklich auch andere Exceptions fangen muss - z.B. so

try {
 /* ... */
} catch (IOException iox) { 
  /* spezifische Behandlung der IOException */
} catch (NumberFormatException nfx) { 
  /* spezifische Behandlung der NumberFormatException */
}

Das klappt aber so nicht - bei dem IOException-Block meckert er, dass diese Exception nicht geworfen wird.

@areafo: In den ssh-Logs ist nichts verdächtiges zu sehen.

 

[Murray]

Das klappt aber so nicht - bei dem IOException-Block meckert er, dass diese Exception nicht geworfen wird.

Dann lohnt sich die Fallunterscheidung umso weniger - denn dann kann die gefangene Exception ja wohl keine IOException sein.

 

[filth]

Doch, das ist sie aber 🙂
Siehe mein Eingangsposting - die wird in der upload - Methode geworfen (Zeile 9)

 

[areafo]

Schwer zu sagen. Weitere Code Teile? Hast du schonmal was uppen können? Cached du das dann im Dateisystem aufm Server? Größe der Datei? Serverumgebung noch was besonderes?

 

[filth]

Schwer zu sagen. Weitere Code Teile? Hast du schonmal was uppen können? Cached du das dann im Dateisystem aufm Server? Größe der Datei? Serverumgebung noch was besonderes?

Welche Codeteile sind noch relevant? Die poste ich dann gerne.

Also der Upload funktioniert in der Regel problemlos. Am Wochenende wurden etwa 16.000 Dateien auf diese Art und Weise übertragen, diese Meldung ist bis jetzt die einzige, die ich bekommen habe. Bei der gleichen Person war es (wie zu erwarten) nicht reproduzierbar.

Die Dateigröße liegt bei etwa 1-2 MB.

Der Server ist ein Debian6 System:

model name      : Intel(R) Core(TM)2 Quad CPU    Q6700  @ 2.66GHz
stepping        : 11
cpu MHz         : 2666.491
cache size      : 4096 KB

Linux backend1 2.6.32-5-amd64 #1 SMP Wed Jan 12 03:40:32 UTC 2011 x86_64 GNU/Linux

 

[areafo]

Achso wenn es nicht reproduzierbar ist naja. Am besten clientseitig und oder serverseitig noch eine Logmethode implementieren die hin u wieder Error logs irgendwo gesammelt auf dem Server ablegen kann, damit du das Monitoren kannst. Das der Thread gecrashed ist und die Connection beendet wurde kann an allem möglichen liegen.

 

[filth]

Ok - mit dem Gedanken die Logs zu übertragen, habe ich auch schon gespielt. Werde das so machen!

Danke!