cassandra-commits mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Jonathan Ellis (JIRA)" <>
Subject [jira] [Commented] (CASSANDRA-1123) Allow tracing query details
Date Sat, 21 Jul 2012 03:34:35 GMT


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:
>             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:

This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:!default.jspa
For more information on JIRA, see:


View raw message