[jira] [Commented] (CASSANDRA-14528) Provide stacktraces for various error logs
[
https://issues.apache.org/jira/browse/CASSANDRA-14528?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16777411#comment-16777411
]
mck commented on CASSANDRA-14528:
-
{quote}So as soon as there's one format argument, then any tailing exception
will also be interpreted as a format argument, and we get
exception.toString().{quote}
To further clarify… while SLF4J proposes to accept the final argument in the
vararg as a throwable, and if so print it as a stack-trace. The LogBack
implementation of the SLF4J Logger does not do this.
> Provide stacktraces for various error logs
> --
>
> Key: CASSANDRA-14528
> URL: https://issues.apache.org/jira/browse/CASSANDRA-14528
> Project: Cassandra
> Issue Type: Improvement
> Components: Legacy/Core
>Reporter: Stefan Podkowinski
>Assignee: Stefan Podkowinski
>Priority: Major
> Fix For: 4.0
>
>
> We should reintroduce some stack traces that have gone missing since
> CASSANDRA-13723 (ba87ab4e954ad2). The cleanest way would probably to use
> {{String.format}} for any custom messages, e.g.
> {{logger.error(String.format("Error using param {}", param), e)}}, so we make
> this more implicit and robust for coming api changes.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-14528) Provide stacktraces for various error logs
[
https://issues.apache.org/jira/browse/CASSANDRA-14528?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16518925#comment-16518925
]
mck commented on CASSANDRA-14528:
-
{quote}Do you really need the nested String.format() within the logger lines?
Why not just pass the exception as the final arg?{quote}
Yes. See CASSANDRA-13723
The {{logger}} parameters for methods {{error(…)|warn(…)|log(…)|debug(…)}} is
either {{(String, Throwable)}} or {{(String, Object…)}}.
So as soon as there's one format argument, then any tailing exception will also
be interrupted as a format argument, and we get {{exception.toString()}}.
CASSANDRA-13723 improved that situation, replacing {{exception.toString()}}
with {{exception.getMessage()}}. While this ticket re-introduces the stack
traces.
> Provide stacktraces for various error logs
> --
>
> Key: CASSANDRA-14528
> URL: https://issues.apache.org/jira/browse/CASSANDRA-14528
> Project: Cassandra
> Issue Type: Improvement
> Components: Core
>Reporter: Stefan Podkowinski
>Assignee: Stefan Podkowinski
>Priority: Major
> Fix For: 4.x
>
>
> We should reintroduce some stack traces that have gone missing since
> CASSANDRA-13723 (ba87ab4e954ad2). The cleanest way would probably to use
> {{String.format}} for any custom messages, e.g.
> {{logger.error(String.format("Error using param {}", param), e)}}, so we make
> this more implicit and robust for coming api changes.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-14528) Provide stacktraces for various error logs
[
https://issues.apache.org/jira/browse/CASSANDRA-14528?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16518862#comment-16518862
]
Jeff Jirsa commented on CASSANDRA-14528:
Do you really need the nested String.format() within the logger lines? Why not
just pass the exception as the final arg?
> Provide stacktraces for various error logs
> --
>
> Key: CASSANDRA-14528
> URL: https://issues.apache.org/jira/browse/CASSANDRA-14528
> Project: Cassandra
> Issue Type: Improvement
> Components: Core
>Reporter: Stefan Podkowinski
>Assignee: Stefan Podkowinski
>Priority: Major
> Fix For: 4.x
>
>
> We should reintroduce some stack traces that have gone missing since
> CASSANDRA-13723 (ba87ab4e954ad2). The cleanest way would probably to use
> {{String.format}} for any custom messages, e.g.
> {{logger.error(String.format("Error using param {}", param), e)}}, so we make
> this more implicit and robust for coming api changes.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-14528) Provide stacktraces for various error logs
[
https://issues.apache.org/jira/browse/CASSANDRA-14528?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16518041#comment-16518041
]
Stefan Podkowinski commented on CASSANDRA-14528:
Maybe telling which one of the cql statements caused the error would also be
possible by looking only at the message. But since this code is triggered by a
user, it shouldn't spam the logs too much in any case..
> Provide stacktraces for various error logs
> --
>
> Key: CASSANDRA-14528
> URL: https://issues.apache.org/jira/browse/CASSANDRA-14528
> Project: Cassandra
> Issue Type: Improvement
> Components: Core
>Reporter: Stefan Podkowinski
>Assignee: Stefan Podkowinski
>Priority: Major
> Fix For: 4.x
>
>
> We should reintroduce some stack traces that have gone missing since
> CASSANDRA-13723 (ba87ab4e954ad2). The cleanest way would probably to use
> {{String.format}} for any custom messages, e.g.
> {{logger.error(String.format("Error using param {}", param), e)}}, so we make
> this more implicit and robust for coming api changes.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-14528) Provide stacktraces for various error logs
[
https://issues.apache.org/jira/browse/CASSANDRA-14528?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16518032#comment-16518032
]
mck commented on CASSANDRA-14528:
-
+1 from me.
I know this would have been of significant help diagnosing CASSANDRA-14356
Maybe we don't need the stacktraces in {{CassandraAuthorizer}} as these
exceptions are rather specific already?
> Provide stacktraces for various error logs
> --
>
> Key: CASSANDRA-14528
> URL: https://issues.apache.org/jira/browse/CASSANDRA-14528
> Project: Cassandra
> Issue Type: Improvement
> Components: Core
>Reporter: Stefan Podkowinski
>Assignee: Stefan Podkowinski
>Priority: Major
> Fix For: 4.x
>
>
> We should reintroduce some stack traces that have gone missing since
> CASSANDRA-13723 (ba87ab4e954ad2). The cleanest way would probably to use
> {{String.format}} for any custom messages, e.g.
> {{logger.error(String.format("Error using param {}", param), e)}}, so we make
> this more implicit and robust for coming api changes.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
