[
https://issues.apache.org/jira/browse/CASSANDRA-5322?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13660510#comment-13660510
]
Alex Zarutin commented on CASSANDRA-5322:
-----------------------------------------
>From Sylvain Lebresne:
On Thu, May 16, 2013 at 8:49 PM, Alex Zarutin <[email protected]> wrote:
Ok, I got your point and would implement as you suggest. A couple simple
questions - design proposals
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 log4j-server.properties) 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 log4j-server.properties with
some original logging set ( log4j.logger.org.apache.cassandra.db=info ) 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
log4j-server.properties to log4j.logger.org.apache.cassandra.db=debug
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.
--
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
