That's cool. I did not know that. In my encoder/decoder, I add a character string to the beginning and end to delimit this very thing. I do see the first message going through the client NioSocketConnector to the NioSocketAcceptor. I see in the logs that the message is then parsed on the server side. Then the MINA connection closes. I've put breakpoints on my close function, and those are never hit.
I've tried commenting out the session.write(message) and the connection verifiably stays open when I do not do the write. I've tried sending a null message and get the expected exception that sending null messages are not allowed. Regards. -----Original Message----- From: Emmanuel Lécharny [mailto:[email protected]] Sent: Monday, May 13, 2013 2:21 PM To: [email protected] Subject: Re: Help with NioSocketConnector Le 5/13/13 7:28 PM, Whitener, Winona T. a écrit : > I am finally (at the TRACE level) seeing something odd. The NioProcessor-2 > is spitting out a SENT: message (from the client handler) saying: > > SENT: HeapBuffer[pos=0 lim=0 cap=0: empty] > > But I'm doing the flip(). I'm not adding any carriage returns. I'm not ever > sending out a blank string. Would this be causing the connection to close? Nope. This is the emtpy message used to count the message sent. When we send a message, once it's encoded, we have no way to know when the full message has been sent, as it may be sent in chunks. We add an empty message into the queue which is used as a marker for messages taht are fully sent. Do you see the messages being sent (not the empty ones) -- Regards, Cordialement, Emmanuel Lécharny www.iktek.com
