try with resources and timers...

[Kevin Burton]

I assume this was the intended purpose... but try-with-resources means you can do:

        try( Timer.Context receiveTimer = timer.time() ) {

            return delegate.receive();

        }

... instead of having a finally block.

[Erik van Oosten]

Nice idea.

Two howevers though:
- metrics still targets Java 6
- why would you want to measure how fast your failures are?

Kind regards,
    Erik.


Kevin Burton schreef op 19-06-14 06:58:

--
You received this message because you are subscribed to the Google Groups "metrics-user" group.
To unsubscribe from this group and stop receiving emails from it, send an email to metrics-user...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

-- 
Erik van Oosten
http://www.day-to-day-stuff.blogspot.com/

[Kevin Burton]

Ah... good points.

It's going to be interesting what happens when Java 8 is a bit more stable and deployed everywhere.  That's a pretty big chasm to jump.

Good points about failures.  I didn't consider that.. .however, I'd still like to count them.

... so I would need to figure that out.

[Justin Mason]

On Mon, Jun 23, 2014 at 9:30 PM, Kevin Burton <burto...@gmail.com> wrote:

Good points about failures.  I didn't consider that.. .however, I'd still like to count them.

I have definitely found this to be useful -- a failed attempt to do something is still worth timing/counting, in many situations.  (In fact I'd say it's better to do this, in general, than not to.)  Sometimes it may delay throwing an exception for orders of magnitude more time than the happy-path case would normally take, which causes knock-on impact elsewhere (ie. threadpool capacity), and it's good to have that visible in a dashboard/alarmable by Nagios etc.

In our code, we wrap Timer usage with our own wrapper and have made that object's returned TimerContext-wrapper implement AutoCloseable, allowing try-with-resources to be used. it makes the code quite a bit more readable -- just a shame we have to provide a variable for the scoping Timer object, which often doesn't get accessed by the wrapped code at all….

--j.

[Erik van Oosten]

Those are good points.

Should we change metrics-scala to always measure?

    Erik.

Justin Mason schreef op 24-06-14 11:16:

--
You received this message because you are subscribed to the Google Groups "metrics-user" group.
To unsubscribe from this group and stop receiving emails from it, send an email to metrics-user...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[Matt Brown]

- why would you want to measure how fast your failures are?

I’m confused by this, because all of the code samples in the metrics docs use this identical pattern:

    private final Timer responses = metrics.timer(name(RequestHandler.class, "responses"));

    public String handleRequest(Request request, Response response) {

        final Timer.Context context = responses.time();

        try {

            // etc;

            return "OK";

        } finally {

            context.stop();

        }

    }

Why would you not want to measure the cases where an exception was thrown inside the code block being timed? If you are not updating the Timer on exceptions, then you would miss out when timeouts or other exceptions cause the block being measure to be latent.

[Erik van Oosten]

Matt,

I stand corrected :)

Thanks,
    Erik.


Matt Brown schreef op 25-06-14 19:38: