Mailing-List: contact commits-help@cassandra.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@cassandra.apache.org
Date: Sat, 6 Sep 2014 00:51:28 +0000 (UTC)
From: "graham sanderson (JIRA)" <jira@apache.org>
To: commits@cassandra.apache.org
Message-ID: <JIRA.12737938.1409353094000.7626.1409964688891@Atlassian.JIRA>
In-Reply-To: <JIRA.12737938.1409353094000@Atlassian.JIRA>
References: <JIRA.12737938.1409353094000@Atlassian.JIRA>
 <JIRA.12737938.1409353094097@arcas>
Subject: [jira] [Commented] (CASSANDRA-7849) Server logged error messages
 (in binary protocol) for unexpected exceptions could be more helpful
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 7bit


    [ https://issues.apache.org/jira/browse/CASSANDRA-7849?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14123908#comment-14123908 ] 

graham sanderson commented on CASSANDRA-7849:
---------------------------------------------

Those are the only log statements in the class, so you are right it is easy to turn from DEBUG to something higher.

Just to confirm, you are cool with hiding at DEBUG level any unexpected exception coming thru this code path, or just the channel related ones I modified (there are still users of the original raw {{public static ErrorMessage fromException(Throwable e)}} method). As I say, there isn't a nice way to detect specifically the silly exceptions we've mostly been talking about (connection reset, and timeout)

> 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
>             Fix For: 1.2.19, 2.0.11, 2.1.0
>
>         Attachments: cassandra-1.2-7849.txt
>
>
> 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.3.4#6332)