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
