Hey David, That's exactly what i was looking for some month ago. I did some work on that topic too, but with that done, i gonna be able to greatly simplify my code.
Thanks a lot for that. Jean-Louis stephenconnolly wrote: > > cool > > On 6 May 2010 17:01, David Blevins <[email protected]> wrote: > >> >> On Mar 4, 2010, at 12:41 PM, David Blevins wrote: >> >> > Started looking into how we might finally get some Monitoring support >> into the code. Basic stats and the like viewable via JMX or something >> similar. >> > >> > Still very much in the research phase of all that. If anyone has done >> any work in that area, I'm interested in some tips. Or if anyone has >> been >> on the "user" side of consuming stats and has some "loves" and "hates" to >> share, that's also great info -- hopefully our impl would stick close to >> the >> loves and steer clear of the hates. >> > >> > And of course, if there are specific stats that anyone would like, >> definitely feel encouraged to speak up. No reason we can't put those >> higher >> in the priority list. >> >> Been back at this one the last two weeks. Have some pretty neat code in >> so >> far. >> >> I started with a copy of Martin Traverso's (an Apache guy) tiny jmxutil >> code which scans objects for @Managed annotated methods and creates a >> ModelMBean based on those methods. The more I started writing actual >> stats >> though, the less I liked the ModelMBean approach as it can only handle >> methods which then requires a lot of pointless getters just for the JMX >> tooling. ModelMBeans are also pretty rigid in that one object == one >> mbean, >> so it isn't possible to "roll up" attributes in to one basic MBean if >> those >> attributes are methods of different java objects. >> >> I'm not a fan of having internal code structure exposed to users when in >> most cases it doesn't benefit them and simply subjects them to more >> brittle >> finer views: do users care that in my Pool object I have a "stats" object >> and in that object there are other "stats" objects and do they really >> need >> an individual MBean for each and every one of these fine grained objects? >> No, of course not. What makes my life easy as a developer, doesn't >> always >> make their lives easy as a user. >> >> Anyway, so I wrote my own little annotation based JMX exporter. You pass >> in an object that has fields and/or methods annotated with @Managed. It >> will inspect all those fields/methods and if any of them are types that >> also >> are marked @Managed, it will walk down those types and collect its >> fields/methods. So it's a basic recursive tree walk, starting with the >> root >> object, that rolls up everything it finds as one flat list of JMX >> attributes. It also allows these fields/methods to be private in scope, >> so >> it isn't necessary to "dirty" your design to get complete stats. >> >> The result is something exposes a nice clean view like this one: >> >> >> https://issues.apache.org/jira/secure/attachment/12443866/jmx-monitoring.png >> >> That's the view of our stateless pool stats via JConsole. >> >> Still have a few "wires" to hookup, but it's looking good. Next part >> will >> be getting stats for each method invocation on a bean. >> >> Comments welcome! :) >> >> >> -David >> >> >> >> > > -- View this message in context: http://openejb.979440.n4.nabble.com/Re-Monitoring-tp2132887p2133789.html Sent from the OpenEJB Dev mailing list archive at Nabble.com.
