Browse Source
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 src.read() won't throw an exception and we will not call flush(). Flush is performed only after src.read() was blocked and thrown an InterruptedIOException exception, this guarantees that we flush all the data available in src so far (src.read() 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 <dmitry.neverov@gmail.com>stable-4.3
Dmitry Neverov
9 years ago
1 changed files with 17 additions and 5 deletions
Loading…
Reference in new issue