cassandra-commits mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Sam Overton (JIRA)" <j...@apache.org>
Subject [jira] (CASSANDRA-13156) Introduce an interface to tracing for determining whether a query should be traced
Date Tue, 31 Jan 2017 21:34:51 GMT

    [ https://issues.apache.org/jira/browse/CASSANDRA-13156?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15847549#comment-15847549
] 

Sam Overton commented on CASSANDRA-13156:
-----------------------------------------

The decision is currently made in {{QueryState.traceNextQuery}} so there is currently nothing
to override in the tracing implementation to change this behavior.

> Introduce an interface to tracing for determining whether a query should be traced
> ----------------------------------------------------------------------------------
>
>                 Key: CASSANDRA-13156
>                 URL: https://issues.apache.org/jira/browse/CASSANDRA-13156
>             Project: Cassandra
>          Issue Type: New Feature
>          Components: Observability
>            Reporter: Sam Overton
>            Assignee: Sam Overton
>              Labels: ops
>
> This is a similar idea to CASSANDRA-9193 but following the same pattern that we have
for IAuthenticator, IEndpointSnitch, ConfigurationLoader et al. where the intention is that
useful default implementations are provided, but abstracted in such a way that custom implementations
can be written for deployments where a specific type of functionality is required. This would
then allow solutions such as CASSANDRA-11012 without any specific support needing to be written
in Cassandra.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

Mime
View raw message