`inputstream is closed` error connecting to a slow server

[gtoison]

Hello,
I'm using jsch 2.27.2 to download files from an SFTP server.
Today the server seems a lot slower than usual and I'm getting this error:

Caused by: java.io.IOException: inputstream is closed
	at com.jcraft.jsch.ChannelSftp.fill(ChannelSftp.java:2872)
	at com.jcraft.jsch.ChannelSftp.header(ChannelSftp.java:2898)
	at com.jcraft.jsch.ChannelSftp.start(ChannelSftp.java:254)

It seems to me that header() attemps to read 9 bytes from the input stream, but does not get anything because the (super slow) server has not started replying.

I tried adding a delay Thread.sleep(Duration.ofMinutes(1)); before that line:

jsch/src/main/java/com/jcraft/jsch/ChannelSftp.java

Line 250 in 90a7d9e

header = header(buf, header);

The workaround seems to work albeit obviously slowing things down.

Would you agree that this seems like a bug?
IMO the fill() method (or its caller) should somehow loop when it does not read enough data.

The commented out code seems to indicate that this was the intent at some point:

jsch/src/main/java/com/jcraft/jsch/ChannelSftp.java

Lines 2862 to 2879 in 90a7d9e

	private int fill(byte[] buf, int s, int len) throws IOException {
	int i = 0;
	int foo = s;
	while (len > 0) {
	i = io_in.read(buf, s, len);
	if (i <= 0) {
	throw new IOException("inputstream is closed");
	// return (s-foo)==0 ? i : s-foo;
	}
	s += i;
	len -= i;
	}
	return s - foo;
	}
	private void skip(long foo) throws IOException {
	while (foo > 0) {
	long bar = io_in.skip(foo);

[norrisjeremy]

Hi @gtoison,

I think there is more going on here than your analysis may indicate.
The io_in is a MyPipedInputstream object, which is defined in Channel.java and extends the JDK's base PipedInputStream implementation.

As MyPipedInputStream does not override the base read(byte[] b, int off, int len) method, that means it will only return a value > 0 or -1 or throw an exception, as it will always read at least one byte, as can be seen here.

This means since you are seeing Caused by: java.io.IOException: inputstream is closed thrown, the read() call is returning -1, which would seem to indicate that the MyPipedInputStream has been closed on the writer side and is no longer functional, and thus no amount of looping would correct that condition.

Thanks,
Jeremy

[gtoison]

Thanks for looking into this!

Indeed the read call was returning -1, but I also tried adding a loop (until 9 bytes were read instead of waiting) and eventually it was able to read the header.
Then it failed a bit later saying that the stream was closed.

I'm not sure what is the exact semantic of -1 here but it looked a bit like there was more data after it. Merely waiting was a workaround, that also seems to indicate that the server was preparing an answer but hadn't closed the stream.

Unfortunately the server is back to answering fast so I can't reproduce the issue.

[norrisjeremy]

Hi @gtoison,

I'm struggling to understand how you could have been in a situation where the read call returned -1, yet then later recovered by ignoring the return value and instead looping until all 9 bytes were read, as analysis of the PipedInputStream code should demonstrate that is impossible.

It would mean that the closedByWriter variable seen here transitioned from a value of true to false, which would appear to be impossible since there is no code present in that class that sets it to a value of false besides when it is initialized here.

Without further evidence and analysis, I'm disinclined to make any changes, since the description of events you are seeing doesn't seem possible, at least in the way in which you describe.

Thanks,
Jeremy

[gtoison]

I'm most probably confused with the loop comment, because I tried that as a last resort and didn't have time to analyse it. Let's forget about that part.

The "sleep() before reading the header" did however solve the problem, but I had to wait for a minute to make it reliable, and that was too long to be acceptable.
I also observed that WinSCP was able to (slowly) connect and download files, so there seems to be a case when jsch's implementation has trouble connecting.

[norrisjeremy]

Hi @gtoison,

My best guess as to what is happening is that the base socket read is timing out here.
In the exception handler seen here, eventually the SocketTimeoutException is rethrown here.
This in turn causes the Session to call disconnect() here.
And this in turn results in disconnect being called on the ChannelSftp object here.

My suggestion to try and counteract a slow server is:

• Increase the socket timeout via Session.setTimeout().
• And/or increase the serverAliveCountMax via Session.setServerAliveCountMax().

Thanks,
Jeremy

[gtoison]

Sorry for the belated answer, I was on holiday with limited access to my computer.

Thanks for the pointers, when the issue occured I tried session.setTimeout(6000000); and channel.connect(6000000); but that did not help.
I was not aware of Session.setServerAliveCountMax() I'll look into it, thank you!