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

Robert Stupp commented on CASSANDRA-9193:
-----------------------------------------

TBH using JSR233 stuff for logging is not a good idea.
Using a scripting language (either JavaScript or any other) will add a 
significant amount of overhead to each request. And even worse, that penalty 
increases when JS is invoked concurrently.

IMO we know for sure that implementations using internal 2.1 APIs of will no 
longer work in 3.0. Having such a thing could possibly break the upgrade from 
2.1 to 3.0.

I like the idea to pass a clean interface (as proposed by Sylvain) and probably 
a logger instance to a (Java) UDF. Such a logger could be named according to 
the keyspace+table names so its logging level can be easily configured using 
JMX and logger config files.

> Facility to write dynamic code to selectively trigger trace or log for queries
> ------------------------------------------------------------------------------
>
>                 Key: CASSANDRA-9193
>                 URL: https://issues.apache.org/jira/browse/CASSANDRA-9193
>             Project: Cassandra
>          Issue Type: New Feature
>            Reporter: Matt Stump
>
> I want the equivalent of dtrace for Cassandra. I want the ability to 
> intercept a query with a dynamic script (assume JS) and based on logic in 
> that script trigger the statement for trace or logging. 
> Examples 
> - Trace only INSERT statements to a particular CF. 
> - Trace statements for a particular partition or consistency level.
> - Log statements that fail to reach the desired consistency for read or write.
> - Log If the request size for read or write exceeds some threshold
> At some point in the future it would be helpful to also do things such as log 
> partitions greater than X bytes or Z cells when performing compaction. 
> Essentially be able to inject custom code dynamically without a reboot to the 
> different stages of C*. 
> The code should be executed synchronously as part of the monitored task, but 
> we should provide the ability to log or execute CQL asynchronously from the 
> provided API.
> Further down the line we could use this functionality to modify/rewrite 
> requests or tasks dynamically.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

Reply via email to