In theory the the logging configurator is watching the log4j-server.properties file and check for changes every 10 seconds. I've nevery had much luck with it, but assumed it was me getting something wrong.
Or you can modify the values on the fly using the setLog4jLevel() on the StorageService MBean via JMX. It will log "set log level to…" to say the value has changed.
On 5/06/2012, at 9:58 AM, Bryce Godfrey wrote:
From: aaron morton [mailto:email@example.com]
Sent: Monday, June 04, 2012 11:15 AM
Subject: Re: 1.1 not removing commit log files?
Apply the local hint mutation follows the same code path and regular mutations.
When the commit log is being truncated you should see flush activity, logged from the ColumnFamilyStore with "Enqueuing flush of " messages.
If you set DEBUG logging for the org.apache.cassandra.db.ColumnFamilyStore it will log if it things the CF is clean and no flush takes place.
If you set DEBUG logging on org.apache.cassandra.db.commitlog.CommitLog we will see if the commit log file could not be deleted because a dirty CF was not flushed.
On 2/06/2012, at 4:43 AM, Rob Coli wrote:
But that talks about segments not being cleared at startup. Does not explain
why they were allowed to get past the limit in the first place.
Perhaps the commit log size tracking for this limit does not, for some
reason, track hints? This seems like the obvious answer given the
state which appears to trigger it? This doesn't explain why the files
aren't getting deleted after the hints are delivered, of course...
AIM>ALK - firstname.lastname@example.org
YAHOO - rcoli.palominob
SKYPE - rcoli_palominodb