Home | About | Sematext search-lucene.com search-hadoop.com
NEW: Monitor These Apps!
elasticsearch, apache solr, apache hbase, hadoop, redis, casssandra, amazon cloudwatch, mysql, memcached, apache kafka, apache zookeeper, apache storm, ubuntu, centOS, red hat, debian, puppet labs, java, senseiDB
 Search Hadoop and all its subprojects:

Switch to Plain View
HBase >> mail # dev >> deprecating (old) metrics in favor of metrics2 framework


+
Ted Yu 2012-07-07, 14:23
+
Jonathan Hsieh 2012-07-09, 16:28
+
Ted Yu 2012-07-09, 16:35
+
Ted Yu 2012-07-09, 19:28
+
Elliott Clark 2012-07-09, 21:34
+
lars hofhansl 2012-07-09, 23:47
+
Ted Yu 2012-07-09, 23:52
+
lars hofhansl 2012-07-09, 23:56
+
Otis Gospodnetic 2012-07-10, 04:05
+
Ted Yu 2012-07-10, 08:45
+
Gary Helmling 2012-07-10, 18:26
+
Ted Yu 2012-07-10, 19:02
+
Gary Helmling 2012-07-10, 20:29
+
Ted Yu 2012-07-10, 20:35
+
Gary Helmling 2012-07-10, 20:55
+
Ted Yu 2012-07-10, 21:03
+
Alex Baranau 2012-07-10, 22:24
+
Elliott Clark 2012-07-10, 22:33
+
Ted Yu 2012-07-10, 23:14
+
Andrew Purtell 2012-07-10, 23:54
+
Elliott Clark 2012-07-10, 23:58
+
Alex Baranau 2012-07-11, 16:29
+
Elliott Clark 2012-07-11, 17:50
+
Andrew Purtell 2012-07-11, 18:57
Copy link to this message
-
Re: deprecating (old) metrics in favor of metrics2 framework
Yep.  This is pretty darn close to DI.  I would be willing to change the
patch that I just put up to use Guice if that's what people wanted.  I know
some of our classes could use some DI loving to help with testability.

On Wed, Jul 11, 2012 at 11:57 AM, Andrew Purtell <[EMAIL PROTECTED]>wrote:

> On Wed, Jul 11, 2012 at 10:50 AM, Elliott Clark <[EMAIL PROTECTED]>
> wrote:
> [...]
> >
> > The reflection option seems like it would be a big perf hit.  Reflection
> > basically means that nothing ever gets inlined so all function calls into
> > metrics2 code would be very expensive.  Since it seems like we are adding
> > more and more instrumentation this perf impact would only grow.
> >  In addition as more hadoop versions come out all of our reflection code
> > would get much more complicated and brittle.
> >
> > The conditionally loaded jar would be nice in that the JIT would only see
> > one version of the factory classes on the classpath and everything could
> be
> > optimized just like any other jvm run jit'd code. In addition there are
> > other places that we use reflection to do things conditionally and a
> > conditionally loaded jar would be nice.
>
> Coprocessors are a solution close to conditionally loaded JARs: there
> is not reflection, very frequently executed code would be JITed, the
> only thing missing is direct inlining.
>
> More and more (useful) metrics are going into hot paths, we want all
> three I think.
>
> We keep inching toward DI.
>
> Best regards,
>
>    - Andy
>
> Problems worthy of attack prove their worth by hitting back. - Piet
> Hein (via Tom White)
>
+
Stack 2012-07-12, 08:23
+
Elliott Clark 2012-07-13, 00:11
+
Elliott Clark 2012-07-10, 21:01
NEW: Monitor These Apps!
elasticsearch, apache solr, apache hbase, hadoop, redis, casssandra, amazon cloudwatch, mysql, memcached, apache kafka, apache zookeeper, apache storm, ubuntu, centOS, red hat, debian, puppet labs, java, senseiDB