cassandra-commits mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Alex Zarutin (JIRA)" <j...@apache.org>
Subject [jira] [Commented] (CASSANDRA-5322) Make dtest logging more granular
Date Fri, 17 May 2013 09:13:16 GMT

    [ 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

Mime
View raw message