[
https://issues.apache.org/jira/browse/CASSANDRA-7807?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Robert Stupp updated CASSANDRA-7807:
------------------------------------
Attachment: 7807-v4.txt
Proabilistic tracing:
Nope - that was my first thought (check on {{connection==null}}).
But it goes via code paths like this in {{QueryMessage}}:
{code}
if (isTracingRequested())
{
tracingId = UUIDGen.getTimeUUID();
state.prepareTracingSession(tracingId);
}
if (state.traceNextQuery())
{
state.createTracingSession(connection);
{code}
And with {{state.createTracingSession(connection);}} it has a connection
reference. Problem is that {{isTracingRequested}} returns true for both
probabilistic and explicit tracing.
We could add an _if (probabilisticTracing) { pass null connection reference }_
(and omit the additional boolean) but it looks ugly to me - and the meaning of
_connection==null_ for trace-complete event wouldn’t be clear.
TransportException:
Reason for relying on {{RuntimeException}} is CASSANDRA-8560 in which we made
{{CassandraException}} an unchecked exception. But you’re right - better leave
it as is for now and clean it up in CASSANDRA-8809.
debug-cql:
Yes - exactly this exception. Its origin in somewhere in the JMX implementation
code. (No clue why the JMX code just cannot say, that it failed to bind.)
Opened CASSANDRA-9069 for this. It doesn’t fail with 2.0 and 2.1 - so it looks
like a change on trunk broke it.
> Push notification when tracing completes for an operation
> ---------------------------------------------------------
>
> Key: CASSANDRA-7807
> URL: https://issues.apache.org/jira/browse/CASSANDRA-7807
> Project: Cassandra
> Issue Type: Sub-task
> Components: Core
> Reporter: Tyler Hobbs
> Assignee: Robert Stupp
> Priority: Minor
> Labels: client-impacting, protocolv4
> Fix For: 3.0
>
> Attachments: 7807-v2.txt, 7807-v3.txt, 7807-v4.txt, 7807.txt
>
>
> Tracing is an asynchronous operation, and drivers currently poll to determine
> when the trace is complete (in a loop with sleeps). Instead, the server
> could push a notification to the driver when the trace completes.
> I'm guessing that most of the work for this will be around pushing
> notifications to a single connection instead of all connections that have
> registered listeners for a particular event type.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
