Yes, throwing the InterruptedException sounds better to me. Please raise an issue.
2013/7/30 Marian Seitner <[email protected]> > 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 sessionChannelExec 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 OFchannelExecOpenFuture.await();if > (!channelExecOpenFuture.isOpened()) { // handle error} > // wait until transfer is donechannelExec.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, 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 > -- ----------------------- Guillaume Nodet ------------------------ Red Hat, Open Source Integration Email: [email protected] Web: http://fusesource.com Blog: http://gnodet.blogspot.com/
