Hi, On Mar 1, 2013, at 4:56 AM, Ian Boston <i...@tfd.co.uk> wrote:
> On 1 March 2013 20:17, Carsten Ziegeler <cziege...@apache.org> wrote: >> Hi, >> >> I agree with Felix here - we should have a coherent story here and JMX >> looks like a good solution to me as well. As outlined in the post that >> started this thread, using JMX from an implementation pov is pretty >> simple. > > To be honest extending StandardMBean is not the issue. Doing it in a > way thats safe and low impact is, as you pointed out when talking > about earlier attempts to generate stats. If each bundle has its own > implementation we will re-invent the wheel, and getting even simple > counters right with no synchronisation is not as simple as volatile > int x; i++; Its not hard by has to be done in the right way. > >> So are there any concerns or problems for using JMX from a client pov? > > Depends on who you talk to. > Most sysops people dont like JMX due to the cost of querying it and > most java devs do like it because it has GUI tools. Most sysops tools > have bridges that spin up a JVM, query JMX and convert the stats into > some other format, (Resmon XML, RRDTool). That uses a minimum of 64MB > of RAM and sysops people tend to get a bit agitated by that when they > compare it to what a python/bash/c command uses. > >> No REST interface is not really an issue and I guess it would be easy >> to write a JMX over REST bridge :) > > It would and it could live in a separate optional bundle for anyone > that wanted it and I could write a JMX Bean ontop of the map as I did > for the Jackrabbit RepositoryStatistics I really like Jolokia (http://www.jolokia.org/) as a JMX/HTTP bridge. It comes out of jmx4perl and is ASLv2 licensed. They already provide an OSGi bundle which can just be dropped in and works. I started to write a Sling-specific bundlization which would use repository credentials rather than user/password hard coded in a configuration file (similar to the WebConsole). Unless there's some specific defect, let's just use this. Justin > > Best Regards > Ian > >> >> Regards >> Carsten >> >> 2013/3/1 Felix Meschberger <fmesc...@adobe.com>: >>> Hi >>> >>> I really appreciate this discussion. But I would like to get to a point >>> where we create a proper future-proof (as much as possible) architecture >>> which properly integrates with the current situation: >>> >>> * JMX is the system of choice for systems management >>> * The Web Console is the respective system of choice >>> for web based interactive tooling >>> * Don't reinvent wheels >>> >>> I would really like to highlight the last point: I would prefer to reuse >>> existing functionality and libraries as much as possible instead of >>> reinventing our own stuff using yet another channel. >>> >>> Regards >>> Felix >>> >>> Am 22.02.2013 um 23:59 schrieb Ian Boston: >>> >>>> Hi, >>>> Whilst writing the MBeans in the event bundle I started thinking about >>>> monitoring inside Sling. IMHO there are not enough to really know what >>>> a instance under load is doing. Much though I like JMX it comes with >>>> implementation and runtime overhead which I don't much like. >>>> >>>> Runtime: >>>> * Running with JMX enabled doesn't add any overhead, but once a client >>>> is connected there is some (some reports upto 3% of resources). >>>> * You have to remember to enable it, and most of the time JVMs are not >>>> enabled. By the time you really need it, its often too late. >>>> * JMX is not restful. >>>> >>>> Implementation >>>> * MBeans are not that hard to implement with the OSGi Whiteboard, but >>>> they have to be implemented. >>>> >>>> Alternatives. >>>> In Jackarabbit there is/was a statistics class [1], which IIUC uses >>>> counters and time series stored in a map. The service can then be >>>> queries to extract the values by wrapping in an MBean or Servlet. >>>> >>>> I think the approach could be generalised and extended so that >>>> anything in the container could use the service to record metrics. The >>>> api might look something like >>>> >>>> public interface Statistics { >>>> >>>> /** >>>> * Increment a counter by 1 >>>> */ >>>> void increment(String counterName); >>>> >>>> /** >>>> * Record a double value in a timeseries. >>>> */ >>>> void record(String timeSeriesName, double value); >>>> >>>> /** >>>> * Record a long value in a timeseries. >>>> */ >>>> void record(String timeSeriesName, long value); >>>> >>>> } >>>> >>>> and (so that any reference can be optional on a service >>>> implementation, the final is a hint to hotspot to inline) >>>> >>>> public final class StatisticsUtils { >>>> >>>> private StatisticsUtils() { >>>> } >>>> >>>> public static void increment(Statistics statistics, String counterName) { >>>> if ( statistics != null ) { >>>> statistics.increment(counterName); >>>> } >>>> } >>>> >>>> ... etc for the other methods .. >>>> } >>>> >>>> >>>> >>>> >>>> The service would need to deal with all the implementation details >>>> (including concurrency and speed). The service implementation would >>>> also come with a servlet endpoint (under /system/*) and/or single JMX >>>> MBean. >>>> >>>> Anything that wanted to record stats would then bind to the service >>>> and use it. I think this would avoid the issues mentioned above with >>>> wide scale MBean usage. >>>> >>>> WDYT? >>>> >>>> (apologies for the noise if this already exists, and if so, please >>>> treat it as a question: where and how do we record stats?) >>>> >>>> Ian >>>> >>>> >>>> >>>> >>>> 1 http://wiki.apache.org/jackrabbit/Statistics >>> >>> >>> -- >>> Felix Meschberger | Principal Scientist | Adobe >>> >>> >>> >>> >>> >>> >>> >> >> >> >> -- >> Carsten Ziegeler >> cziege...@apache.org
