[
https://issues.apache.org/jira/browse/CASSANDRA-11117?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15548934#comment-15548934
]
Joel Knighton commented on CASSANDRA-11117:
-------------------------------------------
I considered that as well. My main concern was that it masks the difference
between the two different behaviors of having a genuinely high timestamp delta
and have the appearance of one due to counter behavior/empty LivenessInfo/etc,
but the more I think about it, the more I think the approach you describe above
is better. In the case where it is a particular storage engine path (as I
described above), these wouldn't be recurring, so they would be quickly lost to
histogram decay anyway.
I'll update the patch - thanks!
> ColUpdateTimeDeltaHistogram histogram overflow
> ----------------------------------------------
>
> Key: CASSANDRA-11117
> URL: https://issues.apache.org/jira/browse/CASSANDRA-11117
> Project: Cassandra
> Issue Type: Bug
> Reporter: Chris Lohfink
> Assignee: Joel Knighton
> Priority: Minor
> Fix For: 2.2.x, 3.0.x, 3.x
>
>
> {code}
> getting attribute Mean of
> org.apache.cassandra.metrics:type=ColumnFamily,name=ColUpdateTimeDeltaHistogram
> threw an exceptionjavax.management.RuntimeMBeanException:
> java.lang.IllegalStateException: Unable to compute ceiling for max when
> histogram overflowed
> {code}
> Although the fact that this histogram has 164 buckets already, I wonder if
> there is something weird with the computation thats causing this to be so
> large? It appears to be coming from updates to system.local
> {code}
> org.apache.cassandra.metrics:type=Table,keyspace=system,scope=local,name=ColUpdateTimeDeltaHistogram
> {code}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
