[
https://issues.apache.org/jira/browse/CASSANDRA-5322?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13660506#comment-13660506
]
Alex Zarutin commented on CASSANDRA-5322:
-----------------------------------------
>From Sylvain Lebresne:
> I saw set_log_level(), however the problem is much more complex.
But is it really? I know that lots of things can be controlled though the log4j
files, but the right question is what do we need. We certainly don't need
to meddle with the full generality of the log4j conf as far as ccm is concerned.
As far as CASSANDRA-5322 is concerned, all that Brandon complained about
initially was to be able to log specific classes to specific levels. And what
I'm saying is that:
1) it's fairly simple to modify set_log_level to handle that case.
2) it's something that can generally be useful for ccm users, even outside the
scope of the dtests. And while I can see myself doing something like:
ccm setloglevel DEBUG --class="org.apache.cassandra.db"
while doing some debugging, because that's quick and easy, I do not see
myself copy the log4j file somewhere, modify it manually the right line
(which involves googling usually because I don't know log4j syntax that
well) and then call something like:
ccm updatelog4j <path_to_my_modified_log4j>
because that's just too cumbersome.
So I'm saying, why no start by such simple and generally useful modification
since it happens to also solve the problem of CASSANDRA-5322.
As for future usage, we'll see. I'm not totally convinced we'd need much more
than that tbh. Maybe we'll need a way to add a new appender, maybe. We will
still have the option to add a way to replace the full log4j file, but even if
we do that, the modification of set_log_level I'm suggesting above will still
be useful as it'll be simpler in the most common cases.
--
Sylvain
> Make dtest logging more granular
> ---------------------------------
>
> Key: CASSANDRA-5322
> URL: https://issues.apache.org/jira/browse/CASSANDRA-5322
> Project: Cassandra
> Issue Type: Test
> Reporter: Ryan McGuire
> Assignee: Alex Zarutin
>
> From Brandon: We need a way (might need to go in ccm, I haven't looked) to
> just set one class to DEBUG or TRACE, like we'd do in
> conf/log4-server.properties but with an env var preferably, so I can control
> it via buildbot, since it's better at reproducing some issues than I am
> sometimes, but I don't want to run the full hammer debug all the time. Also,
> a way to set Tester.allow_log_errors to false via an env var, since sometimes
> there's an error there that takes a while to fix but is cosmetic, and in the
> meantime I want to catch new failures so we don't fall behind.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira