cassandra-commits mailing list archives

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


Alex Zarutin commented on CASSANDRA-5322:

>From Sylvain Lebresne:

On Thu, May 16, 2013 at 8:49 PM, Alex Zarutin <> wrote:

    Ok, I got your point and would implement as you suggest. A couple simple questions - design

    1) keep changes. I guess, we keep them just between ccm create and ccm remove, so once
we remove the cluster, all lo4j changes that we added by ccm setloglevel DEBUG --class="org.apache.cassandra.db"
and that ARE NOT set in original (checkout-ed version of are gone.

Yep, that's what I would do (keep the change only for the lifetime of the ccm cluster). Basically
mimick how it's done for the current global log level, if only for consistency sake.

    2) updating already set log level. If we have with some original
logging set ( ) or having this logging set by ccm
setloglevel INFO --class="org.apache.cassandra.db", and we call ccm setloglevel DEBUG --class="org.apache.cassandra.db",
it should be changed into to

Ideally, we'd allow updating an already set log level. Basically, ccm setloglevel DEBUG --class="org.apache.cassandra.db"
should always end up with the package in debug mode.

    3) Do we need to have bulk set logging? Or one in a time is more than enough for now?

One at a time is probably good enough for now. At least for the command line it's probably
cleaner anyway. For the python code itself, if it's not more complicated to do some bulking,
then why not, but I doubt anyone will complain either way.

> Make dtest logging more granular 
> ---------------------------------
>                 Key: CASSANDRA-5322
>                 URL:
>             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/ 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:

View raw message