# JSch - inputstream is closed



## filth (14. Mrz 2011)

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 (15. Mrz 2011)

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


----------



## filth (15. Mrz 2011)

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 (15. Mrz 2011)

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


----------



## filth (15. Mrz 2011)

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 (15. Mrz 2011)

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 (15. Mrz 2011)

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


----------



## filth (15. Mrz 2011)

Murray hat gesagt.:


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




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 (15. Mrz 2011)

filth hat gesagt.:


> 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 (15. Mrz 2011)

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


----------



## areafo (15. Mrz 2011)

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 (15. Mrz 2011)

areafo hat gesagt.:


> 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 (15. Mrz 2011)

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 (15. Mrz 2011)

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

Danke!


----------

