You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@mina.apache.org by Srikanth J <sh...@gmail.com> on 2009/12/15 19:11:48 UTC

TCP half-open connection question

Hi
I am facing a problem with tcp half-open connection.  Would really
appreciate any thoughts on the issue

The application uses mina tcp server (mina version - 1.1.7) with a
MLLP codec (MLLP codec is provided by apache-camel).  The problem is
that this application runs behind a hardware load balancer which does
a tcp half-open service ping to monitor if application is still
available.  The half-open involves load balancer sending a SYNC,
receiving the ACK from mina server, but not sending a ACK back (not
completing 3way hankshake) and then sending a Reset and FIN commands.
This is resulting in the following exception being thrown every time
half-open is done

org.apache.camel.CamelException: java.io.IOException: Connection reset
by peer (errno:232)
        at org.apache.camel.component.mina.MinaConsumer$ReceiveHandler.exceptionCaught(MinaConsumer.java:90)
        at org.apache.mina.common.support.AbstractIoFilterChain$TailFilter.exceptionCaught(AbstractIoFilterChain.java:564)
        at org.apache.mina.common.support.AbstractIoFilterChain.callNextExceptionCaught(AbstractIoFilterChain.java:345)
        at org.apache.mina.common.support.AbstractIoFilterChain.access$1000(AbstractIoFilterChain.java:53)
        at org.apache.mina.common.support.AbstractIoFilterChain$EntryImpl$1.exceptionCaught(AbstractIoFilterChain.java:643)
        at org.apache.mina.common.IoFilterAdapter.exceptionCaught(IoFilterAdapter.java:75)
        at org.apache.mina.common.support.AbstractIoFilterChain.callNextExceptionCaught(AbstractIoFilterChain.java:345)
        at org.apache.mina.common.support.AbstractIoFilterChain.access$1000(AbstractIoFilterChain.java:53)
        at org.apache.mina.common.support.AbstractIoFilterChain$EntryImpl$1.exceptionCaught(AbstractIoFilterChain.java:643)
        at org.apache.mina.filter.executor.ExecutorFilter.processEvent(ExecutorFilter.java:224)
        at org.apache.mina.filter.executor.ExecutorFilter$ProcessEventsRunnable.run(ExecutorFilter.java:264)
        at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:650)
        at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:675)
        at org.apache.mina.util.NamePreservingRunnable.run(NamePreservingRunnable.java:51)
        at java.lang.Thread.run(Thread.java:595)
Caused by: java.io.IOException: Connection reset by peer (errno:232)
        at sun.nio.ch.FileDispatcher.read0(Native Method)
        at sun.nio.ch.SocketDispatcher.read(SocketDispatcher.java:21)
        at sun.nio.ch.IOUtil.readIntoNativeBuffer(IOUtil.java:233)
        at sun.nio.ch.IOUtil.read(IOUtil.java:200)
        at sun.nio.ch.SocketChannelImpl.read(SocketChannelImpl.java:207)
        at org.apache.mina.transport.socket.nio.SocketIoProcessor.read(SocketIoProcessor.java:218)
        at org.apache.mina.transport.socket.nio.SocketIoProcessor.process(SocketIoProcessor.java:198)
        at org.apache.mina.transport.socket.nio.SocketIoProcessor.access$400(SocketIoProcessor.java:45)
        at org.apache.mina.transport.socket.nio.SocketIoProcessor$Worker.run(SocketIoProcessor.java:485)
        ... 2 more

Is this a known issue (i did look up the mail archive and did some
googling, dint find much) or is this happening because of any possible
wrong configuration of mina?
thanks in advance
Shreeks

Re: TCP half-open connection question

Posted by Srikanth J <sh...@gmail.com>.
> Sounds to me plain normal, as soon as the load balanced send a badly crafted
> message to the stack. You want your handler to know that the connection has
> been brutally terminated, in order to close the session and free all the
> resources you have allocated for this session, no ?
>
> Check on the load balancer side to see if it can send something a bit
> smarter.
>
> Another possibility would be to tune the MLLP codec to handle such a
> terminaison.

Gotcha... not sure why i complicated it.  I wrongly assumed, mina
should have been handling this scenario.  Its probably for the MLLP
codec to catch the exception and gulp it or maybe even the layer on
top it based on the design.

Thanks very much for the quick response.

Re: TCP half-open connection question

Posted by Emmanuel Lecharny <el...@gmail.com>.
Srikanth J a écrit :
> Hi
> I am facing a problem with tcp half-open connection.  Would really
> appreciate any thoughts on the issue
>
> The application uses mina tcp server (mina version - 1.1.7) with a
> MLLP codec (MLLP codec is provided by apache-camel).  The problem is
> that this application runs behind a hardware load balancer which does
> a tcp half-open service ping to monitor if application is still
> available.  The half-open involves load balancer sending a SYNC,
> receiving the ACK from mina server, but not sending a ACK back (not
> completing 3way hankshake) and then sending a Reset and FIN commands.
> This is resulting in the following exception being thrown every time
> half-open is done
>
> org.apache.camel.CamelException: java.io.IOException: Connection reset
> by peer (errno:232)
>         at org.apache.camel.component.mina.MinaConsumer$ReceiveHandler.exceptionCaught(MinaConsumer.java:90)
>         at org.apache.mina.common.support.AbstractIoFilterChain$TailFilter.exceptionCaught(AbstractIoFilterChain.java:564)
>         at org.apache.mina.common.support.AbstractIoFilterChain.callNextExceptionCaught(AbstractIoFilterChain.java:345)
>         at org.apache.mina.common.support.AbstractIoFilterChain.access$1000(AbstractIoFilterChain.java:53)
>         at org.apache.mina.common.support.AbstractIoFilterChain$EntryImpl$1.exceptionCaught(AbstractIoFilterChain.java:643)
>         at org.apache.mina.common.IoFilterAdapter.exceptionCaught(IoFilterAdapter.java:75)
>         at org.apache.mina.common.support.AbstractIoFilterChain.callNextExceptionCaught(AbstractIoFilterChain.java:345)
>         at org.apache.mina.common.support.AbstractIoFilterChain.access$1000(AbstractIoFilterChain.java:53)
>         at org.apache.mina.common.support.AbstractIoFilterChain$EntryImpl$1.exceptionCaught(AbstractIoFilterChain.java:643)
>         at org.apache.mina.filter.executor.ExecutorFilter.processEvent(ExecutorFilter.java:224)
>         at org.apache.mina.filter.executor.ExecutorFilter$ProcessEventsRunnable.run(ExecutorFilter.java:264)
>         at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:650)
>         at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:675)
>         at org.apache.mina.util.NamePreservingRunnable.run(NamePreservingRunnable.java:51)
>         at java.lang.Thread.run(Thread.java:595)
> Caused by: java.io.IOException: Connection reset by peer (errno:232)
>         at sun.nio.ch.FileDispatcher.read0(Native Method)
>         at sun.nio.ch.SocketDispatcher.read(SocketDispatcher.java:21)
>         at sun.nio.ch.IOUtil.readIntoNativeBuffer(IOUtil.java:233)
>         at sun.nio.ch.IOUtil.read(IOUtil.java:200)
>         at sun.nio.ch.SocketChannelImpl.read(SocketChannelImpl.java:207)
>         at org.apache.mina.transport.socket.nio.SocketIoProcessor.read(SocketIoProcessor.java:218)
>         at org.apache.mina.transport.socket.nio.SocketIoProcessor.process(SocketIoProcessor.java:198)
>         at org.apache.mina.transport.socket.nio.SocketIoProcessor.access$400(SocketIoProcessor.java:45)
>         at org.apache.mina.transport.socket.nio.SocketIoProcessor$Worker.run(SocketIoProcessor.java:485)
>         ... 2 more
>
> Is this a known issue (i did look up the mail archive and did some
> googling, dint find much) or is this happening because of any possible
> wrong configuration of mina?
>   

Sounds to me plain normal, as soon as the load balanced send a badly 
crafted message to the stack. You want your handler to know that the 
connection has been brutally terminated, in order to close the session 
and free all the resources you have allocated for this session, no ?

Check on the load balancer side to see if it can send something a bit 
smarter.

Another possibility would be to tune the MLLP codec to handle such a 
terminaison.

-- 
Regards,
Cordialement,
Emmanuel Lécharny
www.nextury.com