On 2.8.14 11:27 , Davide Giannella wrote:
StopwatchLogger sl = new StopwatchLogger(FooBar.class);
// ...
public void foo() {
sl.start();
// perform all sort of things
sl.split(performed some operations);
// perform other things
sl.stop(operation completed);
}
then by setting
On 04/08/2014 09:35, Michael Dürig wrote:
One thing that concerns me is the static reference to the executor
service. It might keep the JVM from terminating properly as it is
never shut down. A better approach might be to create it on the fly in
the start method and shut it down in the stop
On 4.8.14 10:47 , Davide Giannella wrote:
On 04/08/2014 09:35, Michael Dürig wrote:
One thing that concerns me is the static reference to the executor
service. It might keep the JVM from terminating properly as it is
never shut down. A better approach might be to create it on the fly in
the
On 04/08/2014 10:55, Michael Dürig wrote:
...
Agreed, I think this is the better approach.
...
Sure. This was just an idea. We can as well leave it out and add it
once we think such a thing is needed.
Anyhow here is the amended version
http://goo.gl/xUcPdY
If you're fine with the amended
On 4.8.14 11:26 , Davide Giannella wrote:
On 04/08/2014 10:55, Michael Dürig wrote:
...
Agreed, I think this is the better approach.
...
Sure. This was just an idea. We can as well leave it out and add it
once we think such a thing is needed.
Anyhow here is the amended version
On 02/08/2014 14:40, Chetan Mehrotra wrote:
Hi Davide,
Recently Ian pointed to Metrics [1] project which is related to such
timing measurements. It might be helpful to use this (via a wrapper)
to measure timings in critical areas in Oak. So have a look at that
also
Chetan Mehrotra
[1]
On 04/08/2014 11:37, Michael Dürig wrote:
If you're fine with the amended version which already include Closeable
and custom logger I can file an issue ticket, and push it to trunk. We
can work any refactoring/improving from there on.
Sure, let's go ahead!
On 23/06/2014 14:26, Davide Giannella wrote:
On 23/06/2014 13:57, Michael Dürig wrote:
+1 in general. However,
- although it results in nice code on the client side, I'm a bit
reluctant about putting all the code into the instance initialiser.
it was my concern as well. But don't see that
Hi Davide,
Recently Ian pointed to Metrics [1] project which is related to such
timing measurements. It might be helpful to use this (via a wrapper)
to measure timings in critical areas in Oak. So have a look at that
also
Chetan Mehrotra
[1] http://metrics.codahale.com/
On Sat, Aug 2, 2014 at
+1 in general. However,
- although it results in nice code on the client side, I'm a bit
reluctant about putting all the code into the instance initialiser.
- how about reusing org.apache.jackrabbit.oak.stats.Clock instead of
using Guava's Stopwatch? If necessary we could still implement
Hello team,
in the warm laziness of a summer Saturday I was thinking about a way for
having in oak a timing facility for logging/benchmarking critical part
of the code. Something that we could put the logging to DEBUG and we
start see the information.
I started writing this quick sample
11 matches
Mail list logo
