You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@mina.apache.org by Matthew Phillips <ma...@mattp.name> on 2007/05/19 05:47:22 UTC
MINA 1.0.2 to 1.1.0: change in session close semantics?
Hi, I just upgraded a system I'm working on from MINA 1.0.2 to 1.1.
Some tests started failing, specifically ones that test closing a
client's connection. The client in this system sends a disconnect
request, which the server ACK's and then closes the connection, i.e.
// server's handing of a disconnect request message
session.write (new DisconnRply (message));
session.close ();
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?
Cheers,
Matthew.
Re: Closing and flushing messages (DIRMINA-382)
Posted by Trustin Lee <tr...@gmail.com>.
On 8/23/07, Matthew Phillips <ma...@mattp.name> wrote:
> 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 :)
If you are going to close all connections immediately on unbind
without sending any notification message to remote peers, just calling
unbind() will be enough. IoAcceptorConfig has a property called
'disconnectOnUnbind', whose default value is 'true'. If it's set to
true, all connections are automatically closed on unbind.
HTH,
Trustin
--
what we call human nature is actually human habit
--
http://gleamynode.net/
--
PGP Key ID: 0x0255ECA6
Closing and flushing messages (DIRMINA-382)
Posted by Matthew Phillips <ma...@mattp.name>.
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?
Re: MINA 1.0.2 to 1.1.0: change in session close semantics?
Posted by Trustin Lee <tr...@gmail.com>.
Hi Matthew,
On 5/20/07, Matthew Phillips <ma...@mattp.name> 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?
It was because not all users wanted the connection to be closed until
all messages are written out. Providing an explicit method that
closes the connection after all messages are flushed might be useful
like you pointed out. Could you please create a JIRA issue for this
feature?
Thanks,
Trustin
--
what we call human nature is actually human habit
--
http://gleamynode.net/
--
PGP Key ID: 0x0255ECA6
Re: MINA 1.0.2 to 1.1.0: change in session close semantics?
Posted by Matthew Phillips <ma...@mattp.name>.
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?
Cheers,
Matthew.
Re: MINA 1.0.2 to 1.1.0: change in session close semantics?
Posted by peter royal <pr...@apache.org>.
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.
-pete
--
(peter.royal|osi)@pobox.com - http://fotap.org/~osi