OK.  I settled on AAR and it bombed again.  So this is not the answer.

-----Original Message-----
From: Whitener, Winona T. [mailto:[email protected]] 
Sent: Monday, May 13, 2013 2:46 PM
To: [email protected]
Subject: RE: Help with NioSocketConnector

Hello,

I think that (pending more strenuous testing), I have found the problem.  I 
have a portion of the written message that is "AAC".  When I change this to 
"AAR" or "AAB" or just about any other combination of letter, I can get the 
message through.  I don't know why "AAC" is the problem.  Are there other 
abbreviations or strings that are problematic?

Thanks,
Winona

-----Original Message-----
From: Whitener, Winona T. [mailto:[email protected]] 
Sent: Monday, May 13, 2013 2:31 PM
To: [email protected]
Subject: RE: Help with NioSocketConnector

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 

Reply via email to