Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Add a new Gauge class ValueGauge #231

Closed
wants to merge 1 commit into from

Conversation

comcastrong
Copy link

Hey,
I added a new Gauge class ValueGauge class which can save any gauge value as a long number. Somebody else might need use it. Can you please review it and pull merge to your master? If you have any questions, please let me know. My email is : yongjun_rong@cable.comcast.com
Thank you.
Yongjun Rong

@codahale
Copy link
Contributor

This doesn't merge cleanly, but it's also not broadly applicable to most usages of Metrics. Returning a constant value doesn't need much in the way of optimization.

@codahale codahale closed this Apr 24, 2012
@comcastrong
Copy link
Author

ok. I also fixed this issue mojodna/metricsd#2 by adding the new ValueGauge class. By the way, what do you mean optimization here? Do you mean most people prefer to use the RatioGauge, PercentGauge?

@codahale
Copy link
Contributor

I mean, it's optimizing the following code:

new Gauge<Long>() {
    @Override
    public Long value() {
        return 33;
    }
};

You're the first person to want to do this, so unless other people speak up about this I'm not going to add more complexity to Metrics.

@comcastrong
Copy link
Author

That way cannot get the latest gauge value. Please refer to mojodna/metricsd#2 . In MetricsRegistry,

public <T> Gauge<T> newGauge(MetricName metricName,
                                 Gauge<T> metric) {
        return getOrAdd(metricName, metric);
    }

It will return the first metric always. The metrics value never get changed.

@codahale
Copy link
Contributor

I know.

The gauge is responsible for returning the most recent value. This is not the responsibility of the registry.

@comcastrong
Copy link
Author

The gauge itself cannot reset the value to a new value if there is way to change the value inside the existing gauge in the registry. That's why I have to add this to the class Metrics

/**
     * Given a new gauge Long value, registers it under the given metric name.
     *
     * @param metricName the name of the metric
     * @param value    the gauge value
     * @return {@code ValueGauge}
     */
    public static ValueGauge newGauge(MetricName metricName,
                                        Long metricValue) {

        ValueGauge gauge = (ValueGauge) DEFAULT_REGISTRY.newGauge(metricName, new ValueGauge());
        gauge.set(metricValue);
        return gauge;
    }

@codahale
Copy link
Contributor

Ok, I'm not sure what problem you're trying to solve. The issue you're linking to seems unrelated to the code you're posting.

If you want a mutable gauge, make a mutable gauge in your own application. I will not accept this patch.

@comcastrong
Copy link
Author

It's your decision. The issue I linked to is not related. I miss understood it. The problem I'm trying to solve is that the gauge registered in the MetricsRegistry should be able to change the value from outside. If it use the optimization way you provided to instantiate a new gauge instance by override the value method. The gauge value in the MetricsRegistry never get changed because it always returns the first gauge instance with the first gauge value.
Thanks
Yongjun Rong

@comcastrong
Copy link
Author

Another question, we found in metrics, it will attach ".value" for gauge and ".count" for counter in the end of the graphite stats scheme name. Like for example, when sending in "jmx.test", it will show up as "jmx.test.count" in graphite after it pass through the metrics. Can you please explain what the reason you want that extension string to be added?
Thank you.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

2 participants