Another peculiar thing that I've noticed.... Just before the write, I did a System.out for the following:
Session.isClosing() (false) Session.isConnected() (true) Session.isReaderIdle()(false) Session.isReadSuspended()(false) Session.isWriterIdle()(false) Session.isWriteSuspended()(false) I got the same results after the write. So between when the write is fired and when it shows up in the handler is whatever is triggering the connection to close. Do I need to suspend the read temporarily while writing maybe? -----Original Message----- From: Whitener, Winona T. [mailto:[email protected]] Sent: Tuesday, May 14, 2013 8:59 AM To: [email protected] Subject: RE: Help with NioSocketConnector I finally just dropped a new exception and stack trace on the sessionClosed(IoSession session) method. The results: java.lang.Exception: testing against close at communication.socket.MinaClientHandler.sesionClosed(MinaClientHandler.java:57) at org.apache.mina.core.filterchain.DefaultIoFilterChain$TailFilter.sessionClosed(DefaultIoFilterChain.java:642) at org.apache.mina.core.filterchain.DefaultIoFilterchain.callNextSessionClosed(DefaultIoFilterChain.java:382) at org.apache.mina.core.filterchain.DefaultIoFilterChain.access$900(DefaultIoFilterChain.java:47) at org.apache.mina.core.filterchain.DefaultIoFilterChain$EntryImpl$1.sessionClosed(DefaultIoFilterChain.java:750) at org.apache.mina.filter.codec.ProtocolCodecfilter.sessionClosed(ProtocolCedecFilter.java:369) at org.apache.core.filterchain.DefaultIoFilterChain.callNextSessionClosed(DefaultIoFilterChain.java:382) at org.apache.core.filterchain.DefaultIoFitlerChain.access$900(DefaultIoFilterIoChain.java:47) at org.apache.core.filterchain.DefaultIoFilterChain$EntryImpl$1.sessionClosed(DefaultIoFilterChain.java:750) at org.apache.mina.filter.logging.LoggingFilter.sessionClosed(LoggingFilter.java:238) at org.apache.mina.core.filterchain.DefaultIoFilterChain.callNextSessionClosed(DefaultIoFilterChain.java:382) at org.apache.mina.core.filterchain.DefaultIoFilterChain.access$900(DefaultIoFilterChain.java:47) at org.apache.mina.core.filterchain.DefaultIoFilterChain$EntryImpl$1.sessionClosed(DefaultIoFilterChain.java:750) at org.apache.mina.core.filterchain.IoFilterAdapter.sessionClosed(ioFilterAdapter.java:88) at org.apache.core.filterchain.DefaultIoFilterChain.callNextSessionClosed(DefaultIoFilterChain.java:382) at org.apache.mina.core.filterchain.DefaultIoFilterChain.fireSessionClosed(DefaultIoFilterChain.java:375) at org.apache.mina.core.service.IoServiceListenerSupport.fireSessionDestroyed(IoServiceListenerSupport.java:244) at org.apache.mina.core.polling.AbstractPollingIoProcessor.removeNow(AbstractPollingIoProcessor.java:600) at org.apache.mina.core.polling.AbstractPollingIoProcessor.removeSessions(AbstractPollingIoProcessor.java:560) at org.apache.mina.core.polling.AbstractPollingIoProcessor.access$800(AbstractPollingIoProcessor.java:67) at org.apache.mina.core.polling.AbstractPollingIoProcessor$Processor.run(AbstractPollingIoProcessor.java:1132) at org.apache.mina.util.NamePreservingRunnable.run(NamePreservingRunnable.java:64) at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1110) at java.util.concurrent.ThreadPoolExecutor.$Worker.run(ThreadPoolExecutor.java:603) at java.lang.Thread.run(Thread.java:722) This is when I do a session.write(message) when message is passed in as an argument. Ironically, commenting out this line will allow it to run fine. Giving it an explicit string (i.e. session.write("Mymessage") ) may or may not work--it's a toss up. I've tried doing all lower case (mixed results), a numeric string ("123456"), a plain string ("quick brown fox"). I can attach my stack trace from the message sent event as well if you want. -----Original Message----- From: Whitener, Winona T. [mailto:[email protected]] Sent: Tuesday, May 14, 2013 7:49 AM To: [email protected] Subject: RE: Help with NioSocketConnector My apologies--I mistyped. > if (receivedEndSequence && !ioBuffer.hasRemaining()) { << I > don't have any more remaining. > //logging > out.write(fullMessage); > return true; > } To be honest, I am not sold that I need this at all. I put it in place over a generic TextLineEncoder to see if maybe my connection closing problem was related to a specific character sequence or to a break because of buffer size or something like that. Is there anything else that I can try? Is there any control sequences that might be coming up? I implemented the KnockKnock server functionality with MINA and was convinced that it could do the bi-directional communication on a single connection that I needed. That works fine. I used the same code in this project and the connection completely fails--apparently without any sort of recourse since no errors are thrown. Yours in frustration. -----Original Message----- From: Emmanuel Lécharny [mailto:[email protected]] Sent: Tuesday, May 14, 2013 4:01 AM To: [email protected] Subject: Re: Help with NioSocketConnector A few comments inline... Le 5/13/13 10:29 PM, Whitener, Winona T. a écrit : > Please forgive wonky capitals. I'm having to type this from computer to > computer. No exceptions are being recorded. No exceptions are being caught. > > It's definitely not the prettiest code and needs cleaning, but I am unable to > track down why the connection is closing here. > > Thank you for your help. > > public class CodecFactory extends TextLineEncoder implements > ProtocolCodecFactory { > public static String EOM = "//endmsg//"; > public static String BOM = "//stmsg//"; > > public ProtocolEncoder getEncoder(IoSession ioSession) { > return (ProtocolEncoder) new CustomEncoder(); > } > > public ProtocolDecoder getDecoder(IoSession ioSession) { > return (ProtocolDecoder) new CustomDecoder(); > } > } > > Public class CustomDecoder extends CumulativeProtocolDecoder { /// > Public Boolean doDecode(<args>) throws Exception { > Try { > Int startPosition = ioBuffer.position(); > Boolean receivedEndSequence = false; > > StringBuffer buffer = new StringBuffer(); Here, I would simply convert the full buffer to a String, instead of accumulating the bytes one by one. > while (ioBuffer.hasRemaining()) { > byte by = ioBuffer.get(); > buffer.append((char)b); > if (buffer.toString().endWith(CodecFactory.EOM)) { > receivedEndSequence = true; > } > } // Now, check if you found the end sequence One question : why are you testing if you still have some bytes in your buffer ? > if (receivedEndSequence && ioBuffer.hasRemaining()) { > //logging > out.write(fullMessage); > return true; > } > } > Catch (Exception e) { > //logging > } > } > } All in all, I don't think that usng a CummulativeProtocolDecoder is helpful. I would rather process the data as they come, dealing with fragmentation by hand. You have more control. -- Regards, Cordialement, Emmanuel Lécharny www.iktek.com
