[jira] Commented: (CASSANDRA-144) make jmx count/latency stuff actually useful

["Eric Evans (JIRA)" <ji...@apache.org>]

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

Eric Evans commented on CASSANDRA-144:
--------------------------------------

The patch as attached causes test failures, but as you pointed out the on IRC, the following fixes that.

--- a/src/java/org/apache/cassandra/utils/TimedStatsDeque.java
+++ b/src/java/org/apache/cassandra/utils/TimedStatsDeque.java
@@ -19,7 +19,7 @@ public class TimedStatsDeque extends AbstractStatsDeque
     private void purge()
     {
         long now = System.currentTimeMillis();
-        while (deque.peek().timestamp < now - period)
+        while (!deque.isEmpty() && deque.peek().timestamp < now - period)
         {
             deque.remove();
         }

+1

> make jmx count/latency stuff actually useful
> --------------------------------------------
>
>                 Key: CASSANDRA-144
>                 URL: https://issues.apache.org/jira/browse/CASSANDRA-144
>             Project: Cassandra
>          Issue Type: Bug
>            Reporter: Jonathan Ellis
>            Assignee: Jonathan Ellis
>         Attachments: 144.patch
>
>
> i just track those since "the beginning of time" it is not very useful for monitoring.  
> (say things are fine for days, then something breaks -- you have to overcome the days of fine-ness in the avg before you can see anything wrong.)
> option 1: reset the counters after each request for data.  problem: then i can't have multiple collectors (which i don't need atm but might be nice to have).
> option 2: keep the last N data points and compute an average on demand, but that's more complicated than just doing a += for each op.
> going to go with option 2.

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.