[ 
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,
>  tr...@8ebeee1-5483-v01-001-trace-filtering-and-tracestate-propagation.txt, 
> [email protected], 
> 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)

Reply via email to