[
https://issues.apache.org/jira/browse/CASSANDRA-1123?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13419737#comment-13419737
]
David Alves commented on CASSANDRA-1123:
----------------------------------------
Thank you for the thorough review.
bq. Inclined to think we should include the parameters along w/ the String
request type on session start. (Object... + toString would be adequate.) Maybe
even use the new List type to store the arguments (CASSANDRA-3647).
In one of the papers this same issue raised privacy concerns that are probably
even more valid for CASSANDRA since it's an open source project. IMO we should
at the very least make this optional if not drop it all together.
bq. Tracing should be asynchronous. StorageProxy.mutate waits for a response,
this is not what we want. Suggest a simple ExecutorService + queue. (If queue
gets full, throw out the tracing events and log a WARN.).
bq. Would like tracing to log.debug the event as well. This will cut down on
duplicate debug/trace code, but also give us a fallback if we can't log it
remotely. This will also cut down on log spam for when we enable debug level
globally – only logging requests at debug where tracing was explicitly enabled
will be a huge improvement.
+1, nice idea, was looking into doing something similar.
bq. get_slice uses startSession instead of startSessionIfRequested.
bq. There's a no-op initialization of trace context in StorageService.
bq. Naming: system_enable_query_details -> system_enable_query__tracing.
TraceSession, TraceSessionState -> TraceSessionContext,
TraceSessionContextThreadLocalState. endSession -> stopSession. getQueryDetails
-> isTracingEnabled.
Most already corrected in current version.
bq. CFMetaData definitions should be with the other hardcoded ones in
CFMetaData.
bq. Let's move helpers that are only used by test code like EVENT_TYPE into the
Test class.
will do!
bq. Still think threadlocals are not the way to go, and this will become more
clear as you try to add useful trace entries. I think you'll end up w/ a trace
session "registry" like we have for MessagingService that we'll look up by
session id. In that vein, I'm not sure what the afterExecute business is
supposed to be doing. That stuff runs on the executor's thread, not the
submitter's.
Current version uses this to trace pre and post stage execution (which are the
only trace events at the moment). I've just finished updating the cli and I'd
like a chance to do some runs as is to get a sense of the usefulness of the
current setup.
bq. Finally, a more generic keyspace name like dsystem would be nice for all
distributed system tables. (We're thinking of using one for CASSANDRA-3706, for
instance.)
will look into/synchronize.
> Allow tracing query details
> ---------------------------
>
> Key: CASSANDRA-1123
> URL: https://issues.apache.org/jira/browse/CASSANDRA-1123
> Project: Cassandra
> Issue Type: New Feature
> Components: Core
> Reporter: Jonathan Ellis
> Assignee: David Alves
> Fix For: 1.2
>
> Attachments: 1123-3.patch.gz, 1123.patch
>
>
> In the spirit of CASSANDRA-511, it would be useful to tracing on queries to
> see where latency is coming from: how long did row cache lookup take? key
> search in the index? merging the data from the sstables? etc.
> The main difference vs setting debug logging is that debug logging is too big
> of a hammer; by turning on the flood of logging for everyone, you actually
> distort the information you're looking for. This would be something you
> could set per-query (or more likely per connection).
> We don't need to be as sophisticated as the techniques discussed in the
> following papers but they are interesting reading:
> http://research.google.com/pubs/pub36356.html
> http://www.usenix.org/events/osdi04/tech/full_papers/barham/barham_html/
> http://www.usenix.org/event/nsdi07/tech/fonseca.html
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
