cassandra-commits mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "graham sanderson (JIRA)" <>
Subject [jira] [Commented] (CASSANDRA-7849) Server logged error messages (in binary protocol) for unexpected exceptions could be more helpful
Date Tue, 16 Sep 2014 22:34:34 GMT


graham sanderson commented on CASSANDRA-7849:

Well our options certainly include calling code path (as it happens the only errors I have
seen, were all client related, and all {{IOException}} and all came from the Message.exceptionCaught

I am happy to do whatever, I'd suggest

1) Leave in the new the extra information in the message (this IS useful) - i.e. IP addresses
of each end of the channel
2) Just use DEBUG level for Message.exceptionCaught code path
3) Possibly make the decision at that code path for ERROR vs DEBUG based on {{instanceof IOException}}?

The crux of the issue (and hence the stuff above) is that the IOException in particular does
not help you distinguish the cause (except by examining the message which is obviously bad)
from being noise or an actual issue... I had leaned towards INFO at some point

Note that this error message is not logged by netty, but originates there , but I think 2)
pretty much covers that (since it is netty specific exception handling)

Thoughts? I'll go ahead and update the patch if we're in agreement (currently with 1,2,3 and
no INFO level)

> Server logged error messages (in binary protocol) for unexpected exceptions could be
more helpful
> -------------------------------------------------------------------------------------------------
>                 Key: CASSANDRA-7849
>                 URL:
>             Project: Cassandra
>          Issue Type: Improvement
>            Reporter: graham sanderson
>            Assignee: graham sanderson
>             Fix For: 1.2.19, 2.0.11
>         Attachments: cassandra-1.2-7849.txt, cassandra-1.2-7849_v2.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 (line
222) Unexpected exception during request
> Connection reset by peer
>         at Method)
>         at
>         at
>         at
>         at
>         at
>         at
>         at
>         at
>         at
>         at java.util.concurrent.ThreadPoolExecutor.runWorker(
>         at java.util.concurrent.ThreadPoolExecutor$
>         at
> {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

View raw message