[
https://issues.apache.org/jira/browse/CASSANDRA-7849?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14116014#comment-14116014
]
graham sanderson commented on CASSANDRA-7849:
---------------------------------------------
Given that this is logging is a side effect of
{{org.apache.cassandra.transport.messages.fromException(Throwable e)}} for
unexpected exception types, and yet the caller generally has some useful
context, my suggestion would be to add an optional {{Object context}} argument
that could be {{.toString}}-ed into the error message if present.
i.e. in this case (the one we are seeing)
{code}
@Override
public void exceptionCaught(final ChannelHandlerContext ctx,
ExceptionEvent e)
throws Exception
{
if (ctx.getChannel().isOpen())
{
ChannelFuture future =
ctx.getChannel().write(ErrorMessage.fromException(e.getCause()));
// On protocol exception, close the channel as soon as the
message have been sent
if (e.getCause() instanceof ProtocolException)
{
future.addListener(new ChannelFutureListener() {
public void operationComplete(ChannelFuture future) {
ctx.getChannel().close();
}
});
}
}
}
{code}
do
{code}
ChannelFuture future =
ctx.getChannel().write(ErrorMessage.fromException(e.getCause(),
ctx.getChannel()));
{code}
> Server logged error messages 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
--
This message was sent by Atlassian JIRA
(v6.2#6252)
