Hi,
I've a question regarding correct handling of client-side initiated transfer
interruption.
Consider the following code to demonstrate the issue (code is called from a
pool thread):
// we have already an established client session
ChannelExec channelExec = clientSession.createChannelExec("myCommand");
// set streams etc.
channelExec.setIn(new FileInputStream("/path/to/huge/file.bin"));
OpenFuture channelExecOpenFuture = channelExec.open();
// do something useful with the OF
channelExecOpenFuture.await();
if (!channelExecOpenFuture.isOpened()) {
// handle error
}
// wait until transfer is done
channelExec.waitFor(ClientChannel.EOF | ClientChannel.CLOSED, 0);
The problem is the last line. If the transfer has to be stopped, e.g. because
the thread is interrupted, then there's no way to react to it. In
AbstractClientChannel.waitFor() line 175 the InterruptedException is silently
swallowed, so my thread blocks until the transfer is done.
Unfortunately using a loop and a short timeout doesn't help either because
Object.wait() clears the interrupted status after an InterruptedException has
been thrown (which is the case here).
Due to time constraints I decided to modify AbstractClientChannel.waitFor() to
throw an InterruptedException so I can initiate a channel close after thread
interruption, which is working quite well so far. Is this a proper solution? If
yes I'd contribute a patch, otherwise I'd be happy to know how to do it right
:-)
Thanks,
Marian
