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
