You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@mina.apache.org by Marian Seitner <ma...@outlook.com> on 2013/07/30 00:45:40 UTC

[SSHD] Client-side initiated connection interruption

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
 		 	   		  

Re: [SSHD] Client-side initiated connection interruption

Posted by Guillaume Nodet <gn...@gmail.com>.
Yes, throwing the InterruptedException sounds better to me.
Please raise an issue.

2013/7/30 Marian Seitner <ma...@outlook.com>

> 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: gnodet@redhat.com
Web: http://fusesource.com
Blog: http://gnodet.blogspot.com/