cassandra-commits mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Ben Chan (JIRA)" <>
Subject [jira] [Commented] (CASSANDRA-5483) Repair tracing
Date Mon, 13 Jan 2014 23:44:05 GMT


Ben Chan commented on CASSANDRA-5483:

Thus far, I've been going under the assumption that it's mostly meant to be used as a combination
of performance profiling and some sort of globally accessible error log (for that particular
repair session), though there will probably easily be enough information there to be able
to extract some stats.

I could use some suggestions on what things (and what level of detail) would be good to trace.
In addition to what I already have, I can only think of a few places in {{Differencer}} and
{{StreamingRepairTask}}, along with a more complete covering of the repair-related error logs.

> Repair tracing
> --------------
>                 Key: CASSANDRA-5483
>                 URL:
>             Project: Cassandra
>          Issue Type: Improvement
>          Components: Tools
>            Reporter: Yuki Morishita
>            Assignee: Ben Chan
>            Priority: Minor
>              Labels: repair
>         Attachments: test-5483-system_traces-events.txt, trunk@8ebeee1-5483-v01-001-trace-filtering-and-tracestate-propagation.txt,
> I think it would be nice to log repair stats and results like query tracing stores traces
to system keyspace. With it, you don't have to lookup each log file to see what was the status
and how it performed the repair you invoked. Instead, you can query the repair log with session
ID to see the state and stats of all nodes involved in that repair session.

This message was sent by Atlassian JIRA

View raw message