cassandra-commits mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Ryan McGuire (JIRA)" <j...@apache.org>
Subject [jira] [Commented] (CASSANDRA-5322) Make dtest logging more granular
Date Mon, 13 May 2013 18:01:21 GMT

    [ https://issues.apache.org/jira/browse/CASSANDRA-5322?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13656184#comment-13656184
] 

Ryan McGuire commented on CASSANDRA-5322:
-----------------------------------------

Pasting what I wrote from an offline discussion:

I think there is a bit of ambiguity in the original request: There's logging in the python
code for dtests, and there's logging in cassandra itself. The conf/log4-server.properties
that Brandon mentioned is in C* (not dtests) for controlling how much logging a single C*
class generates. The only problem with it, is that since it's a static file, the classes that
it sets to DEBUG will be spewing out lots of logs over the course of every test that dtests
defines. If I understand Brandon's request, he wants a way so that we turn on debugging for
a single C* class for the duration of a single dtest only.

To do that we need to make dtests (or possibly ccm) check for an environment variable to turn
on a different debugging strategy for a given dtest. Here's my idea:

We have the default conf/log4-server.properties file, we make a copy of that file someplace
for each dtest configuration we need. Let's assume that the upgrade_through_versions_test.py
exercises the org.apache.cassandra.io.sstable.SSTableMetadata class and we want to debug that
(I don't know that it actually does, this is just an example.) We don't necessarily want
that class to output debugging for all dtests, just upgrade_through_versions_test.py. So we
make a copy of conf/log4-server.properties and add debugging for SSTableMetadata. Then we
create an environment variable like this: DTEST_LOG4_PROPERTIES=upgrade_through_versions_test:/path/to/our/modified_log4-server.properties|some_other_test:/path/to/another/properties .
Dtests (or ccm) takes that environment variable and when it finds it specifies an alternate
config for a dtest, it uses the alternate log4-server.properties file when starting up C*.

Since we're invoking ccm's cluster.populate() directly in the dtests I see two options:

* Add this environment variable check and config file swap inside ccm
* Refactor all of the cluster.populate() calls to a dtest utility function that creates the
cluster in the way we want (adds the right log4j-server.properties file to each node.)

The former is easier, but it adds complexity to ccm. The second way means we have to refactor
pretty much all of our tests, but it gives dtests more control over the environment, which
I think is a win.
                
> 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