[
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
