Hi all,
this is related to the discussion quoted below which lead to
DIRMINA-382.
I'm basically still not sure how to cleanly close down a set of
connections when the protocol involves sending a "disconnect" style
message before closing the socket.
After putting the disconnect messages into the queue for each
session, I'm doing the following:
SocketAcceptor socketAcceptor = ...
Set<InetSocketAddress> addresses = ...
for (InetSocketAddress address : addresses)
{
for (IoSession session : socketAcceptor.getManagedSessions
(address))
session.close ().join (10000);
socketAcceptor.unbind (address);
}
// when I get here I want to be sure we're fully closed down
I'm not sure that (a) this works and (b) whether it's overkill and
unbind () might be doing this. Can someone clarify the semantics, and
perhaps we can get some documentation? I'd be happy to write some
myself once I understand what's going on :)
Cheers,
Matthew.
-----
On 20/05/2007, at 6:24 PM, Matthew Phillips wrote:
On 19/05/2007, at 5:25 PM, peter royal wrote:
On May 18, 2007, at 8:47 PM, Matthew Phillips wrote:
This was all working reliably with 1.0.2, but in 1.1 it seems
that the reply is never seen by the client -- it appears that the
DisconnRply isn't getting flushed on session close. Changing the
code as below fixes the problem:
session.write (new DisconnRply (message)).join (); // added
join ()
session.close ();
While this fixes the problem, I'm worried that it will affect the
server's behaviour by making the message sending unnecessarily
synchronous.
Any ideas? Is this a bug, or was the previous behaviour
unintentional?
Previous behavior was unintentional. To avoid being synchronous,
add IoFutureListener.CLOSE as a listener to the future; it'll
close the socket when the message is sent.
Thanks, that works well.
However, it does seem a somewhat unexpected that a session.close ()
doesn't flush messages already in the queue, as it appeared to
previously. My mental model of MINA is that there are a bunch of
messages in a queue somewhere, in the order they were sent, and
that close () would flush them and then close the underlying
network connection. Because, presumably, if you got as far as
completing a write (), you'd like them to be sent. In this case,
close () seems more like abort () than an orderly shutdown. Can
anyone elaborate on why this isn't the way things work?
