Hi Matthew,
On 5/20/07, Matthew Phillips <[EMAIL PROTECTED]> 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
