cassandra-commits mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "William R. Speirs (JIRA)" <j...@apache.org>
Subject [jira] [Comment Edited] (CASSANDRA-13368) Exception Stack not Printed as Intended in Error Logs
Date Thu, 23 Mar 2017 15:59:41 GMT

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

William R. Speirs edited comment on CASSANDRA-13368 at 3/23/17 3:59 PM:
------------------------------------------------------------------------

[~spodxx@gmail.com] hu, that's pretty curious then. I double-checked and Cassandra is using
SLF4J v1.7.2. From my logs for example:

{noformat}
ERROR [STREAM-OUT-/X.X.X.X] 2017-03-19 20:29:15,224 StreamSession.java:512 - [Stream #ac1424f0-0cfd-11e7-b5a3-cb3016d1596d]
Streaming error occurred
{noformat}

That code is:
{noformat}
501     public void onError(Throwable e)
502     {
503         if (e instanceof SocketTimeoutException)
504         {
505             logger.error("[Stream #{}] Streaming socket timed out. This means the session
peer stopped responding or " +
506                          "is still processing received data. If there is no sign of failure
in the other end or a very " +
507                          "dense table is being transferred you may want to increase streaming_socket_timeout_in_ms
" +
508                          "property. Current value is {}ms.", planId(), DatabaseDescriptor.getStreamingSocketTimeout(),
e);
509         }
510         else
511         {
512             logger.error("[Stream #{}] Streaming error occurred", planId(), e);
513         }
514         // send session failure message
515         if (handler.isOutgoingConnected())
516             handler.sendMessage(new SessionFailedMessage());
517         // fail session
518         closeSession(State.FAILED);
519     }
{noformat}

I'm at a loss as to why {{e}} is not being properly interpreted as {{Throwable}} and therefore
not printing the stack trace. Thoughts?


was (Author: wspeirs):
[~spodxx@gmail.com] hu, that's pretty curious then. I double-checked and Cassandra is using
SLF4J v1.7.2. From my logs for example:

{noformat}
ERROR [STREAM-OUT-/X.X.X.X] 2017-03-19 20:29:15,224 StreamSession.java:512 - [Stream #ac1424f0-0cfd-11e7-b5a3-cb3016d1596d]
Streaming error occurred
{noformat}

That code is:
{noformat}
501     public void onError(Throwable e)
502     {
503         if (e instanceof SocketTimeoutException)
504         {
505             logger.error("[Stream #{}] Streaming socket timed out. This means the session
peer stopped responding or " +
506                          "is still processing received data. If there is no sign of failure
in the other end or a very " +
507                          "dense table is being transferred you may want to increase streaming_socket_timeout_in_ms
" +
508                          "property. Current value is {}ms.", planId(), DatabaseDescriptor.getStreamingSocketTimeout(),
e);
509         }
510         else
511         {
512             logger.error("[Stream #{}] Streaming error occurred", planId(), e);
513         }
514         // send session failure message
515         if (handler.isOutgoingConnected())
516             handler.sendMessage(new SessionFailedMessage());
517         // fail session
518         closeSession(State.FAILED);
519     }
{noformat}

So I'm at a loss as to why {{e}} is not being properly interpreted as {{Throwable}} and therefore
printing the stack trace. Thoughts?

> Exception Stack not Printed as Intended in Error Logs
> -----------------------------------------------------
>
>                 Key: CASSANDRA-13368
>                 URL: https://issues.apache.org/jira/browse/CASSANDRA-13368
>             Project: Cassandra
>          Issue Type: Bug
>            Reporter: William R. Speirs
>            Priority: Trivial
>              Labels: lhf
>             Fix For: 2.1.x
>
>         Attachments: cassandra-13368-2.1.patch
>
>
> There are a number of instances where it appears the programmer intended to print a stack
trace in an error message, but it is not actually being printed. For example, in {{BlacklistedDirectories.java:54}}:
> {noformat}
>         catch (Exception e)
>         {
>             JVMStabilityInspector.inspectThrowable(e);
>             logger.error("error registering MBean {}", MBEAN_NAME, e);
>             //Allow the server to start even if the bean can't be registered
>         }
> {noformat}
> The logger will use the second argument for the braces, but will ignore the exception
{{e}}. It would be helpful to have the stack traces of these exceptions printed. I propose
adding a second line that prints the full stack trace: {{logger.error(e.getMessage(), e);}}
> On the 2.1 branch, I found 8 instances of these types of messages:
> {noformat}
> db/BlacklistedDirectories.java:54:            logger.error("error registering MBean {}",
MBEAN_NAME, e);
> io/sstable/SSTableReader.java:512:            logger.error("Corrupt sstable {}; skipped",
descriptor, e);
> net/OutboundTcpConnection.java:228:                    logger.error("error processing
a message intended for {}", poolReference.endPoint(), e);
> net/OutboundTcpConnection.java:314:                logger.error("error writing to {}",
poolReference.endPoint(), e);
> service/CassandraDaemon.java:231:                logger.error("Exception in thread {}",
t, e);
> service/CassandraDaemon.java:562:                logger.error("error registering MBean
{}", MBEAN_NAME, e);
> streaming/StreamSession.java:512:            logger.error("[Stream #{}] Streaming error
occurred", planId(), e);
> transport/Server.java:442:                logger.error("Problem retrieving RPC address
for {}", endpoint, e);
> {noformat}
> And one where it'll print the {{toString()}} version of the exception:
> {noformat}
> db/Directories.java:689:            logger.error("Could not calculate the size of {}.
{}", input, e);
> {noformat}
> I'm happy to create a patch for each branch, just need a little guidance on how to do
so. We're currently running 2.1 so I started there.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

Mime
View raw message