cassandra-commits mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Ben Chan (JIRA)" <j...@apache.org>
Subject [jira] [Commented] (CASSANDRA-5483) Repair tracing
Date Sat, 08 Mar 2014 14:48:45 GMT

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

Ben Chan commented on CASSANDRA-5483:
-------------------------------------

Thanks for the catch. Hopefully the fix is as easy as:

{noformat}
// using OpenJDK's source code for Executors.newCachedThreadPool() as a reference
new DebuggableThreadPoolExecutor(0, Integer.MAX_VALUE, 60L, TimeUnit.SECONDS,
                                 new SynchronousQueue<Runnable>(),
                                 new NamedThreadFactory("RepairJobTask"));
{noformat}

Also note that {{v02-01}} added {{CompactionExecutor extends DebuggableThreadPoolExecutor}},
so that is something else to watch out for.

---

Re: {
Oops (I'm normally K&R).

Re: github
Move to a github workflow, or some sort of hybrid github/JIRA?

---

I guess the last caveat here is that most (I may have left in a few) of the old non-{{trace}}
function overloads are gone, so the server isn't going to work with old versions of {{nodetool}}.

And a newer {{nodetool}} still won't work with older server versions. There may be some tricks
you can do with JMX, but I don't have deep knowledge there. Maybe adding function overloads
from the future (I noticed a similar trick in {{MessagingService.java}}).

And there is a lot of repetitious parallel code with the tracing and logging together. But
that shouldn't affect the external functionality.


> Repair tracing
> --------------
>
>                 Key: CASSANDRA-5483
>                 URL: https://issues.apache.org/jira/browse/CASSANDRA-5483
>             Project: Cassandra
>          Issue Type: Improvement
>          Components: Tools
>            Reporter: Yuki Morishita
>            Assignee: Ben Chan
>            Priority: Minor
>              Labels: repair
>         Attachments: 5483-v06-04-Allow-tracing-ttl-to-be-configured.patch, 5483-v06-05-Add-a-command-column-to-system_traces.events.patch,
5483-v06-06-Fix-interruption-in-tracestate-propagation.patch, ccm-repair-test, test-5483-system_traces-events.txt,
trunk@4620823-5483-v02-0001-Trace-filtering-and-tracestate-propagation.patch, trunk@4620823-5483-v02-0002-Put-a-few-traces-parallel-to-the-repair-logging.patch,
trunk@8ebeee1-5483-v01-001-trace-filtering-and-tracestate-propagation.txt, trunk@8ebeee1-5483-v01-002-simple-repair-tracing.txt,
v02p02-5483-v03-0003-Make-repair-tracing-controllable-via-nodetool.patch, v02p02-5483-v04-0003-This-time-use-an-EnumSet-to-pass-boolean-repair-options.patch,
v02p02-5483-v05-0003-Use-long-instead-of-EnumSet-to-work-with-JMX.patch
>
>
> 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
(v6.2#6252)

Mime
View raw message