I agree with you. I didn't notice this way. Thank you ! But anyway, don't you think, all of the Mina team and other people, that when one call the close().join() function on a session, one could assume that it will wait (with the join() feature) until all pending sending messages are really sent ?
For me, my logic is that if I call close().join(), it should wait for all messages to be gone. As the usual meaning of close (filechannel, stream, ...). If not, every users need to check if their message are really gone, whatever the process, by hand, before closing the session in a secure way. Of course, we can all put write(...).join() for the last write operation, but sometime it can be not so easy. For example, I saw in the mailing list a recent bug with IoStream if I recall well. However, I found a way to make it correct at least for me (waiting on getScheduledWriteRequests() to be 0 before calling close()). Perhaps it could be a good idea to change a bit the standard close function in MINA ? There is probably better ways than mine inside MINA. Frederic Selon peter royal <[EMAIL PROTECTED]>: > On Jul 27, 2006, at 3:49 PM, Frédéric Brégier wrote: > > 4) Close feature : > > I was a bit surprise when I found the following situation. > > Consider the server is making a loop to send about 20 messages > > (each of them > > being a part of a file). > > At the end of the sends (session.write()), I put a session.close() > > and then > > a join() on the CloseFuture. > > I make a trace of all messageSent, sessionClosed, ... > > and I observed the following : > > - 10 messageSent (message really sent), > > - 1 sessionClosed appears > > - and of course the 10 last messages to sent are never sent (since the > > session is closed). > > Put a callback on the last WriteFuture you get from writing, and in > that, perform your close. That way it will close after sending the > last message. > > -pete > > > -- > [EMAIL PROTECTED] - http://fotap.org/~osi > > > >
