[
https://issues.apache.org/jira/browse/CASSANDRA-1123?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13419733#comment-13419733
]
Jonathan Ellis commented on CASSANDRA-1123:
-------------------------------------------
Nit: rest of the code base places static imports after non-static.
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).
get_slice uses startSession instead of startSessionIfRequested.
a session named execute_cql_query is not very useful. Should use queryString
instead. May want to just push the CQL tracing into (cql3) QueryProcessor.
This will mean less code to duplicate in the native CQL protocol handler.
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.)
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.
CFMetaData definitions should be with the other hardcoded ones in CFMetaData.
Let's move helpers that are only used by test code like EVENT_TYPE into the
Test class.
There's a no-op initialization of trace context in StorageService.
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.
Naming: system_enable_query_details -> system_enable_query__tracing.
TraceSession, TraceSessionState -> TraceSessionContext,
TraceSessionContextThreadLocalState. endSession -> stopSession.
getQueryDetails -> isTracingEnabled.
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.)
> 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
