Quantcast

java.io.IOException: Connection reset by peer problem

classic Classic list List threaded Threaded
6 messages Options
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

java.io.IOException: Connection reset by peer problem

conrad_
Hi everyone

I am currently using MINA 1.0.10 and am only new to MINA for the last
couple of months. I have searched the documentation, forums and mailing
lists for past few days trying to find if anyone else has this problem
but haven't been successful.

I am using an IoAcceptor to bind certain Handlers to certain ports. Each
port will have connections from GPRS modules that report in their
location and other data. Each GPRS module reports their data differently
so different handlers are required for each module.

Anyway the problem is, I get the following exception every now and then
(it seems randomly) and am not sure what is causing the exception to occur:

java.io.IOException: Connection reset by peer
        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:206)

                           at
sun.nio.ch.SocketChannelImpl.read(SocketChannelImpl.java:207)

                           at
org.apache.mina.transport.socket.nio.SocketIoProcessor.read(SocketIoProcessor.java:254)

                           at
org.apache.mina.transport.socket.nio.SocketIoProcessor.process(SocketIoProcessor.java:234)

                           at
org.apache.mina.transport.socket.nio.SocketIoProcessor.access$400(SocketIoProcessor.java:46)

                           at
org.apache.mina.transport.socket.nio.SocketIoProcessor$Worker.run(SocketIoProcessor.java:539)

                           at
org.apache.mina.util.NamePreservingRunnable.run(NamePreservingRunnable.java:51)

        at java.lang.Thread.run(Thread.java:595)

In the Handler class I add the Filters in the sessionCreated method:
public void sessionCreated(IoSession session) throws Exception {
        if (session.getTransportType() == TransportType.SOCKET) {
            ((SocketSessionConfig)
session.getConfig()).setReceiveBufferSize(2048);
        }

        // custom codec for this device
        session.getFilterChain().addFirst("codec", new ProtocolCodecFilter(
                new CustomTextLineCodecFactory(Charset.forName("UTF-8"))));
        session.getFilterChain().addLast("logger", new LoggingFilter());
    }

The CustomTextLineCodecFactory is a modified class of
TextLineCodecFactory which instead of waiting for a newline character to
determine a message has been received, it waits for there to be 0 bytes
left in the buffer. I've tested it by using the original
TextLineCodecFactory class and the exception still occurs so I fairly
sure that the problem doesn't lie in the decoding/encoding of the data.

Majority of the time the GPRS module reports their data successfully,
but on times it does not, the exception above occurs. And the data that
is being sent is always the same (same format, same EOL characters).

When this exception occurs the session is then closed which should not
happen because the module is required to keep its connection
indefinitely to minimize the cost.

Sometimes this exception occurs when theres 50+ clients connected, 90+
clients, or even only 2 or 3 clients connected. It actually seems like
its occuring randomly and I cannot find the cause of this exception.

Hope that all makes sense, if anyone has any ideas please let me know,
it will be much appreciated. If you require any more information let me
know.

Thanks
Conrad

Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: java.io.IOException: Connection reset by peer problem

elecharny-2
Hi,

On Tue, Jun 2, 2009 at 5:20 AM, Conrad Congrene <[hidden email]> wrote:
> Hi everyone
> Anyway the problem is, I get the following exception every now and then (it
> seems randomly) and am not sure what is causing the exception to occur:
>
> java.io.IOException: Connection reset by peer

The client closed the socket. It's not a MINA problem. Just check to
see what happens on the client side.

<snip/>

> When this exception occurs the session is then closed which should not
> happen because the module is required to keep its connection indefinitely to
> minimize the cost.

It's pretty hard to maintain a session when the client has left !




--
Regards,
Cordialement,
Emmanuel Lécharny
www.iktek.com
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: java.io.IOException: Connection reset by peer problem

conrad_
Thankyou for your reply, but are you sure?

My server used the QuickServer framework before using MINA and this exception never occurred with QS.

The client(s) have not changed, as they connect and behave the same way as always (always keeps the connection), but when they connect to the server that uses MINA, the IOException occurs, but with QS the exception never occured. This is what has lead me to believe that it is a MINA problem.

Could the client had closed the socket because of something happening on the MINA side (something not enabling the client to continue so forcing to close the socket)?

Emmanuel Lecharny wrote
Hi,

On Tue, Jun 2, 2009 at 5:20 AM, Conrad Congrene <conrad@abridge.com.au> wrote:
> Hi everyone
> Anyway the problem is, I get the following exception every now and then (it
> seems randomly) and am not sure what is causing the exception to occur:
>
> java.io.IOException: Connection reset by peer

The client closed the socket. It's not a MINA problem. Just check to
see what happens on the client side.

<snip/>

> When this exception occurs the session is then closed which should not
> happen because the module is required to keep its connection indefinitely to
> minimize the cost.

It's pretty hard to maintain a session when the client has left !




--
Regards,
Cordialement,
Emmanuel Lécharny
www.iktek.com
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: java.io.IOException: Connection reset by peer problem

elecharny-2
On Tue, Jun 2, 2009 at 8:54 AM, conrad_ <[hidden email]> wrote:
>
> Thankyou for your reply, but are you sure?

pretty much. The stack trace is clear about it. "Connection remote by peer"

>
> My server used the QuickServer framework before using MINA and this
> exception never occurred with QS.
>
> The client(s) have not changed, as they connect and behave the same way as
> always (always keeps the connection), but when they connect to the server
> that uses MINA, the IOException occurs, but with QS the exception never
> occured. This is what has lead me to believe that it is a MINA problem.
>
> Could the client had closed the socket because of something happening on the
> MINA side (something not enabling the client to continue so forcing to close
> the socket)?

This is an option. Many application will simply close the connection
if they receive something wrong.

In this case, I would suggest you check what's sent to the client
before the connection is closed. Wireshark could help.

You would also like to use MINA 1.1.7 version, which is much mature,
unless you are stuck with an old version of JDK. Give a try to MINA
2.0.0 too.

--
Regards,
Cordialement,
Emmanuel Lécharny
www.iktek.com
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: java.io.IOException: Connection reset by peer problem

conrad_
I've now updated with MINA 2.0.0 M6 but am still getting the exception.

Nothing should be sent to the client from MINA as every client that connects will send only its GPS data every x minutes. If the data is incorrect or in the wrong format, the client is not made aware of this (my app will just discard it).

I have although added a LoggingFilter to the FilterChain in each session to log what is sent/received and it appears that nothing is sent to the client prior to the exception occurring.

Could this be a memory related issue? Because I've set it up now that say, port 2000 and 2001 use MINA, and port 2002 uses QuickServer. When all were using MINA, port 2002 had the majority of clients connected (~50-90) and the exception would occur there only. But now that 2002 is using QS, I get the same exceptions occurring in both ports 2000 and 2001. The clients connected to these ports also send GPS data but in a different format.

I'm not too sure how else I can overcome this exception, if anyone has any ideas I'd greatly appreciate it

Thanks
Conrad


Emmanuel Lecharny wrote
On Tue, Jun 2, 2009 at 8:54 AM, conrad_ <conrad@abridge.com.au> wrote:
>
> Thankyou for your reply, but are you sure?

pretty much. The stack trace is clear about it. "Connection remote by peer"
>
> My server used the QuickServer framework before using MINA and this
> exception never occurred with QS.
>
> The client(s) have not changed, as they connect and behave the same way as
> always (always keeps the connection), but when they connect to the server
> that uses MINA, the IOException occurs, but with QS the exception never
> occured. This is what has lead me to believe that it is a MINA problem.
>
> Could the client had closed the socket because of something happening on the
> MINA side (something not enabling the client to continue so forcing to close
> the socket)?

This is an option. Many application will simply close the connection
if they receive something wrong.

In this case, I would suggest you check what's sent to the client
before the connection is closed. Wireshark could help.

You would also like to use MINA 1.1.7 version, which is much mature,
unless you are stuck with an old version of JDK. Give a try to MINA
2.0.0 too.

--
Regards,
Cordialement,
Emmanuel Lécharny
www.iktek.com
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: java.io.IOException: Connection reset by peer problem

elecharny-2
On Wed, Jun 3, 2009 at 9:00 AM, conrad_ <[hidden email]> wrote:
>
> I've now updated with MINA 2.0.0 M6 but am still getting the exception.

As it's the client which close the connection, it makes sense. You
have to find why the client is closing the connectio. it's not a
server problem.


--
Regards,
Cordialement,
Emmanuel Lécharny
www.iktek.com
Loading...