[
https://issues.apache.org/jira/browse/CASSANDRA-13368?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15938645#comment-15938645
]
William R. Speirs commented on CASSANDRA-13368:
-----------------------------------------------
[~spo...@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)
