[
https://issues.apache.org/jira/browse/CASSANDRA-7849?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14116474#comment-14116474
]
Michael Shuler commented on CASSANDRA-7849:
-------------------------------------------
Patches are surely welcomed. I have seen a bunch of connection resets (along
with other errors) in recent testing where I'm intentionally saturating the
network and network attached disks. This error is essentially an
indication/symptom of more basic network infrastructure problems, but if you
come up with something that can add some correlation, it might be interesting.
> Server logged error messages (in binary protocol) for unexpected exceptions
> could be more helpful
> -------------------------------------------------------------------------------------------------
>
> Key: CASSANDRA-7849
> URL: https://issues.apache.org/jira/browse/CASSANDRA-7849
> Project: Cassandra
> Issue Type: Improvement
> Reporter: graham sanderson
>
> From time to time (actually quite frequently) we get error messages in the
> server logs like this
> {code}
> ERROR [Native-Transport-Requests:288] 2014-08-29 04:48:07,118
> ErrorMessage.java (line 222) Unexpected exception during request
> java.io.IOException: Connection reset by peer
> at sun.nio.ch.FileDispatcherImpl.read0(Native Method)
> at sun.nio.ch.SocketDispatcher.read(SocketDispatcher.java:39)
> at sun.nio.ch.IOUtil.readIntoNativeBuffer(IOUtil.java:223)
> at sun.nio.ch.IOUtil.read(IOUtil.java:192)
> at sun.nio.ch.SocketChannelImpl.read(SocketChannelImpl.java:379)
> at
> org.jboss.netty.channel.socket.nio.NioWorker.read(NioWorker.java:64)
> at
> org.jboss.netty.channel.socket.nio.AbstractNioWorker.process(AbstractNioWorker.java:109)
> at
> org.jboss.netty.channel.socket.nio.AbstractNioSelector.run(AbstractNioSelector.java:312)
> at
> org.jboss.netty.channel.socket.nio.AbstractNioWorker.run(AbstractNioWorker.java:90)
> at
> org.jboss.netty.channel.socket.nio.NioWorker.run(NioWorker.java:178)
> at
> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145)
> at
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615)
> at java.lang.Thread.run(Thread.java:745)
> {code}
> These particular cases are almost certainly problems with the client driver,
> client machine, client process, however after the fact this particular
> exception is practically impossible to debug because there is no indication
> in the underlying JVM/netty exception of who the peer was. I should note we
> have lots of different types of applications running against the cluster so
> it is very hard to correlate these to anything
--
This message was sent by Atlassian JIRA
(v6.2#6252)
