[
https://issues.apache.org/jira/browse/CASSANDRA-5322?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13656473#comment-13656473
]
Alex Zarutin commented on CASSANDRA-5322:
-----------------------------------------
Hey Ryan and Brandon,
Well, I did not realize that we are talking about getting more logging data of
the cassandra product, not cassandra-dtest.
So, abstracting from ccm tool and nosetest harness - we can deploy the cluster
manually as well as run the tests as pure python code (if needed), we need to
be able to turn on/off logging for the single cassandra class (or multiple
cassandra classes) on the fly: enable logging of the class XXXXX.java -> run
particular test_yyyy.py -> disable logging of the class XXXXX.java. is it
correct?
If so, I suggest a little bit different approach regarding the implementation:
yes, we have (should have) number of the log4j-server.properties files with
different combination of the classes "enabled" for the logging and/or a simple
tool that allows us to generate log4j-server.properties file based in the input
parameter (class name for the extensive logging)
we need to update log4j-server.properties with <configuration
monitorInterval="30">, actually wrap existing content of
log4j-server.properties by <configuration monitorInterval="30"> ....
</configuration>. Logger log4j has the ability to automatically detect changes
to the configuration file and reconfigure itself. If the monitorInterval
attribute is specified on the configuration element and is set to a non-zero
value then the file will be checked the next time a log event is evaluated
and/or logged and the monitorInterval has elapsed since the last check. See the
following for the details:
http://logging.apache.org/log4j/2.x/manual/configuration.html#AutomaticReconfiguration
. However, I have never tried this myself.
so, we startup cassandra with configuration monitorInterval="30" in the
log4j, update log4j-server.properties with the proper log4j configuration file
(with enabled logging of class XXXX), wait for 30 seconds (minimum is 5
seconds) to wait until it is reloaded, run the cassandra-dtest(s), change
log4j-server.properties back, wait another 30 seconds, and run another
cassandra-dtest(s) or leave the cluster.
and yes, this functionality can be build-in into ccm tool
Of course, this "reload" functionality is going to be used in cassandra
"testing" mode only. Instance running Cassandra product as well as running
Cassandra under stress tests, should use log4j configuration w/o <configuration
monitorInterval="30">, since there is a huge impact, that is not tested.
> 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
