[
https://issues.apache.org/jira/browse/CASSANDRA-12643?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15658633#comment-15658633
]
Edward Capriolo edited comment on CASSANDRA-12643 at 11/12/16 12:28 AM:
------------------------------------------------------------------------
{quote}
I think the right fix should actually be on LibratoReporter to print which
metric is overflowed when getting an exception
{quote}
That would be the right fix but that is not the easy fix. Unfortunately, the
abstraction provided by reporters and the Cassandra wrapping. You can not
redefine that functionality without changing the metric-reporting classes.
The code looks like this: (and is not code defined in apache-cassandra)
{noformat}
report(){
for(Gauge g: gauges){
reportGauge(g);
}
for(Counter c: counters){
reportCounter(c);
}
{noformat}
Most reporters do NOT even try catch, throwing any exception/or assertion
generally causes the reporter to fail and result in only some things getting
reported.
I think if we just show the values it would be basically easy to determine why
the algorithm overflows. The name is fairly meaningless. If the values are
0,0,0 and that overflows we can feed that into a unit test and reason about
what it is supposed to do.
was (Author: appodictic):
{quote}
I think the right fix should actually be on LibratoReporter to print which
metric is overflowed when getting an exception
{quote}
That would be the right fix but that is not the easy fix. Unfortunately, the
abstraction provided by reporters only provide you a reportGauge(). You can not
redefine that functionality without changing the metric-reporting classes.
That is really the big problem the code looks like this: (and is not code
defined in apache-cassandra)
{noformat}
report(){
for(Gauge g: gauges){
reportGauge(g);
}
for(Counter c: counters){
reportCounter(c);
}
{noformat}
Basically most reporters do NOT even try catch so throwing any exception
generally just causes the reporter to fail and result in only some things
getting counter. Basically nothing anywhere exceptions any metric to throw any
exception or assertion.
I agree it would be idea to see name/ values. But its not easy.
I think if we just show the values it would be basically easy to determine why
the algorithm overflows. The name is fairly meaningless. If the values are
0,0,0 we can feed that into a unit test and reason about what it is supposed to
do.
> Estimated histograms tend to overflow
> -------------------------------------
>
> Key: CASSANDRA-12643
> URL: https://issues.apache.org/jira/browse/CASSANDRA-12643
> Project: Cassandra
> Issue Type: Bug
> Reporter: Edward Capriolo
> Assignee: Edward Capriolo
>
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
