Skip to main content
diff options
authorDmitry Neverov2015-08-21 11:44:49 -0400
committerDmitry Neverov2015-08-24 11:54:48 -0400
commita86566dcf04df51a445051cf9d12ba9451020a3e (patch)
treed8ec19f19f570080ef15ef760d8f47b2ba10e530 /.gitignore
parent847b3d12584d298d98eee9b2981e8123c067ab52 (diff)
Fix hanging fetch via SSH
Signaling the need to flush() only via the interrupted status of a copying thread doesn't work realiably with jsch. The write() method of com.jcraft.jsch.Session catches the InterruptedException in several places. As a result StreamCopyThread can easily miss the interrupt if it was interrupted during the dst.write() or dst.flush() call. When it happens, StreamCopyThread will not send some data to the remote side and will not get the response back, because remote side will wait for more data from us. The flushCount field incremented during flush() method guarantees we don't miss flush() even if jsch catches InterruptedException in dst.write() or dst.flush() calls. Checking the flushCount after dst.write() is needed because dst.write() can clear interrupt status, in this case the next blocking won't throw an exception and we will not call flush(). Flush is performed only after was blocked and thrown an InterruptedIOException exception, this guarantees that we flush all the data available in src so far ( doesn't block while more is available). FlushCount is reset to 0 only when there were no flush() calls since last blocked read, that means we flushed all data available in src. If there were flush() calls, the interrupt status is restored, so next blocked read will throw InterruptedException and we will flush() again. Change-Id: I692b226edaff502f06235ec05da9052b5fe6478a Signed-off-by: Dmitry Neverov <>
Diffstat (limited to '.gitignore')
0 files changed, 0 insertions, 0 deletions

Back to the top