Mailing-List: contact commits-help@cassandra.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@cassandra.apache.org
Date: Thu, 25 Feb 2016 19:21:18 +0000 (UTC)
From: "Carl Yeksigian (JIRA)" <jira@apache.org>
To: commits@cassandra.apache.org
Message-ID: <JIRA.12917668.1449080105000.147453.1456428078132@Atlassian.JIRA>
In-Reply-To: <JIRA.12917668.1449080105000@Atlassian.JIRA>
References: <JIRA.12917668.1449080105000@Atlassian.JIRA>
 <JIRA.12917668.1449080105120@arcas>
Subject: [jira] [Commented] (CASSANDRA-10805) Additional Compaction Logging
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 7bit


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

Carl Yeksigian commented on CASSANDRA-10805:
--------------------------------------------

I've been looking at logback and how we might be able to use logback directly. The biggest problem is that there isn't a notification for when the log file changes. We need to know that the logfile is changing so that we can log out the sstables that are already on disk so that each logfile is independent (and old ones can be deleted).
We won't be able to use the logback loggers, or logback.xml, because we won't be able to use the loggers as they are currently defined, since additional information needs to be passed on creation of the logger to know what tables' files to log on a new file.
We can still use the infrastructure of logback to be able to execute the mechanics of doing the log rotations so that we aren't responsible for it; it just won't be as seamless as updating the logback.xml files and having it reread it.

> Additional Compaction Logging
> -----------------------------
>
>                 Key: CASSANDRA-10805
>                 URL: https://issues.apache.org/jira/browse/CASSANDRA-10805
>             Project: Cassandra
>          Issue Type: New Feature
>          Components: Compaction, Observability
>            Reporter: Carl Yeksigian
>            Assignee: Carl Yeksigian
>            Priority: Minor
>
> Currently, viewing the results of past compactions requires parsing the log and looking at the compaction history system table, which doesn't have information about, for example, flushed sstables not previously compacted.
> This is a proposal to extend the information captured for compaction. Initially, this would be done through a JMX call, but if it proves to be useful and not much overhead, it might be a feature that could be enabled for the compaction strategy all the time.
> Initial log information would include:
> - The compaction strategy type controlling each column family
> - The set of sstables included in each compaction strategy
> - Information about flushes and compactions, including times and all involved sstables
> - Information about sstables, including generation, size, and tokens
> - Any additional metadata the strategy wishes to add to a compaction or an sstable, like the level of an sstable or the type of compaction being performed


--
This message was sent by Atlassian JIRA
(v6.3.4#6332)