[
https://issues.apache.org/jira/browse/CASSANDRA-5483?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14185252#comment-14185252
]
Joshua McKenzie commented on CASSANDRA-5483:
--------------------------------------------
DebuggableThreadPoolExecutor:
bq. Just to confirm (though I'm mostly sure this is what you mean), Do you mean
that the function name should be changed to something like
createCachedThreadpoolWithMaximumPoolSize?
Yep - just denote that it's max pool size
bq. If an older server version ever initiates a trace, then traceType could be
null. And if it is null, that means that it's a QUERY traceType (since that's
the only kind of trace available in previous versions). If a newer server
version ever sends a null traceType, that should probably be an error, though
nothing like that is being done yet.
Totally legit. I'm fine with that.
bq. I touched on this code change earlier in the paragraph that begins "Note
that I switched some code".
You did, and that's my bad. There's a lot of history on this ticket that I
needed to re-read and that was one of those things. :) I believe the changed
code will behave identically to the original implementation with the caveats
you listed, and so long as we can hand off that swallowed exception to the
JVMStabilityInspector and document that we intend to swallow if things explode,
I have no complaints.
bq. Futures#addCallback uses Uninterruptibles#getUninterruptibly instead of a
plain Future#get, the main difference being that it will keep retrying
Future#get even in the face of InterruptedException.
Not sure whether this would be a problem or not, but replicating previous
behavior would be the safest route.
bq. In the interests of not gratuitously rearranging code, I'll merely see
about adding better comments and making the code less magical.
Less magical is almost always a good thing.
{code} wait(wait); {code}
Reads oddly - might want to tweak naming there. Other than that, isDone on the
review branch comments itself.
nit: a more helpful description for trace_repair would be good. Currently
reads "Use -tr to trace repair"
> 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
> Fix For: 3.0
>
> Attachments: 5483-full-trunk.txt,
> 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,
> 5483-v07-07-Better-constructor-parameters-for-DebuggableThreadPoolExecutor.patch,
> 5483-v07-08-Fix-brace-style.patch,
> 5483-v07-09-Add-trace-option-to-a-more-complete-set-of-repair-functions.patch,
> 5483-v07-10-Correct-name-of-boolean-repairedAt-to-fullRepair.patch,
> 5483-v08-11-Shorten-trace-messages.-Use-Tracing-begin.patch,
> 5483-v08-12-Trace-streaming-in-Differencer-StreamingRepairTask.patch,
> 5483-v08-13-sendNotification-of-local-traces-back-to-nodetool.patch,
> 5483-v08-14-Poll-system_traces.events.patch,
> 5483-v08-15-Limit-trace-notifications.-Add-exponential-backoff.patch,
> 5483-v09-16-Fix-hang-caused-by-incorrect-exit-code.patch,
> 5483-v10-17-minor-bugfixes-and-changes.patch,
> 5483-v10-rebased-and-squashed-471f5cc.patch, 5483-v11-01-squashed.patch,
> 5483-v11-squashed-nits.patch, 5483-v12-02-cassandra-yaml-ttl-doc.patch,
> 5483-v13-608fb03-May-14-trace-formatting-changes.patch,
> 5483-v14-01-squashed.patch,
> 5483-v15-02-Hook-up-exponential-backoff-functionality.patch,
> 5483-v15-03-Exact-doubling-for-exponential-backoff.patch,
> 5483-v15-04-Re-add-old-StorageService-JMX-signatures.patch,
> 5483-v15-05-Move-command-column-to-system_traces.sessions.patch,
> 5483-v15.patch, 5483-v17-00.patch, 5483-v17-01.patch, 5483-v17.patch,
> ccm-repair-test, cqlsh-left-justify-text-columns.patch,
> prerepair-vs-postbuggedrepair.diff, 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,
> tr...@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.3.4#6332)
