Hi Emmanuel, I am in the process of modifying the vysper Socks5 exceptionCaught handler to be more production-ready - handling IOException in a clean way, but was still curious if there was also a problem in MINA, since it states that it could close the connection if it got an IOException. I just wanna make sure we aren't missing another problem.
When we get this fixed and tested, I'll submit it as a patch to Vysper. Thanks, Bob -----Original Message----- From: Emmanuel Lécharny [mailto:[email protected]] Sent: Tuesday, February 21, 2012 1:26 PM To: [email protected] Subject: Re: **URGENT** - possible problem in Mina AbstractPollingIoProcessor -or- Vysper Socks5AcceptorHandler Hi in Socks5Pair, the session is closed this way : target.close(false); Here is the close() Javadoc : "Closes this session immediately or after all queued write requests are flushed. This operation is asynchronous. Wait for the returned CloseFuture if you want to wait for the session actually closed. Specified by: close(...) in IoSession Parameters: rightNow true to close this session immediately (i.e. close()). The pending write requests will simply be discarded. false to close this session after all queued write requests are flushed (i.e. closeOnFlush())." As you can see, by passing 'false', the session will only be closed when the data will have been flushed. Passing 'true' would most certainly fix the issue. I suggest you fill a JIRA requesting for a fix, even providing a patch, if you have tested it and if it solves your issue. PS : http://www.catb.org/~esr/faqs/smart-questions.html#urgent Le 2/21/12 5:51 PM, Bob DeRemer a écrit : > Hi Mina community, > > I've believe I've come across a bug in either: > > > * MINA's AbstractPollingIoProcessor > > * --or-- > > * Vysper's Socks5AcceptorHandler - which extends MINA's > IoHandlerAdapter > > I've stepped the logic and know what's happening [outlined below], and > believe there may be a problem in the Vysper SOCKS5 implementation, but > [based on MINA IoHandler comments], it appears there may be a bug in MINA > when an IOException occurs, too. > > If anyone on this list has any guidance/suggestions, I would GREATLY > appreciate it **as we are now in testing and this is a critical issue for > us**. Also, If you have any further questions, please let me know. > > Thanks in advance, > Bob > > > PROBLEM + TROUBLESHOOTING RESULTS: > > We are using the Vysper [trunk] + Mina [2.0.4]. We are experiencing an > endless loop of SOCKS5 exceptions in Vysper Socks5AcceptorHandler when the > network connection is killed/lost at the client while receiving an incoming > file transfer on the SOCKS5 socket. > > When stepping the Vysper + MINA 2.0.4 code: > > * when the initial session is forcibly closed, the Vysper > Socks5AcceptorHandler.exceptionCaught is called - as expected - with an > IOException > > * this calls Socks5Pair.close(), which closes the respective > Requestor and Target IoSessions - gracefully - NOT forcibly > > o as a result, since there's a lot of data in the pipeline, the MINA > AbstractPollingIoProcessor continues to call FlushNow, which tries to write - > generating another IOException in the exceptionCaught handler > > Based on the MINA IoHandler comments on exceptionCaught, it says MINA will > close the connection automatically, but this does NOT appear to be happening > - at least not while the sessions are still OPENED: > /** > * Invoked when any exception is thrown by user {@link IoHandler} > * implementation or by MINA. If<code>cause</code> is an instance of > * {@link IOException}, MINA will close the connection automatically. > */ > void exceptionCaught(IoSession session, Throwable cause) throws > Exception; > > > Bob DeRemer > Senior Director, Architecture and Development > > [cid:[email protected]] > http://www.thingworx.com<http://www.thingworx.com/> > Skype: bob.deremer.thingworx > O: 610.594.6200 x812 > M: 717.881.3986 > > -- Regards, Cordialement, Emmanuel Lécharny www.iktek.com
