[jira] [Commented] (CASSANDRA-7849) Server logged error messages for unexpected exceptions could be more helpful

["graham sanderson (JIRA)" <ji...@apache.org>]

    [ 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)