directory-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Trustin Lee <trus...@gmail.com>
Subject Re: [MINA] 0.9.0 - Deadlock in SocketIoProcessor
Date Wed, 21 Dec 2005 09:11:31 GMT
2005/12/17, Niklas Therning <niklas@trillian.se>:
>
> I think there is a simple solution to your problem. Try to add a
> ThreadPoolFilter to your SocketConnector's filter chain builder. That
> should make the sessionClosed() call on your DestinationHandler be
> handled in a different thread (not in SocketIoProcessor's worker thread).


Exactly.

Of course, SSLFilter shouldn't block the thread like it does right now
> in initiateClosure. Your approach should work without a
> ThreadPoolFilter. I don't know enough about the implementation details
> of SSLFilter to say why it does block and if it could be fixed. Trustin?


filterClose is invoked when user called IoSession.close().  As specified in
TLS specification, each side should send close_notify message before the
connection is closed.  So, we have to ensure that the message is written
before the connection close request is passed to the IoSessionManager.  To
do so, initiateClosure() waits for WriteFuture for the close_notify message,
by calling join().  The bottom line is that we should not call join() in
filters.  We could sometimes use IoFuture.Callback, but I'm not sure if we
can always use this workaround.

There are two join() calls in SSLFilter.  I can fix the case for
filterClose, but not for onPreRemove because the connection is not going to
be closed and we cannot prevent users from calling IoSession.close() before
close_notify message is written out not using join().

WDYT?

Trustin
--
what we call human nature is actually human habit
--
http://gleamynode.net/
PGP Key ID: 0x854B996C

Mime
View raw message