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
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
