David, I already asked you why you are reinventing the wheel, but it seems, for fun, which is a perfectly ok reason though. However, maybe you'll find some insights on how other people do it here: http://blog.anotheria.net/msk/the-complete-moskito-integration-guide-step-6-moskito-control/and here: http://blog.anotheria.net/msk/case-study-monitoring-a-cluster-of-java-daemon-processes/
regards Leon On Mon, May 19, 2014 at 2:42 PM, David kerber <dcker...@verizon.net> wrote: > On 5/19/2014 8:27 AM, Neven Cvetkovic wrote: > >> On Mon, May 19, 2014 at 8:11 AM, David kerber <dcker...@verizon.net> >> wrote: >> >>> >>> I've uploaded code examples and the JmxExample.war: >>> >>>> https://wiki.apache.org/tomcat/Example%20Application% >>>> 20Exposing%20Internals%20Using%20JMX >>>> >>>> So, just deploy JmxExample.war to your Tomcat instance, open up JMX >>>> console >>>> through JVisualVM or JConsole, and find the MBean, e.g. >>>> JmxExampleApp:type=Counter >>>> >>>> You will see that the internal instance of MyCounter is exposed through >>>> JMX, and you will be able to set the name, initial count, reset the >>>> counter, etc... >>>> >>>> The trick was to use @WebListener that registers the MBean instance with >>>> your MBeanServer upon application deployment. Your MBean instance will >>>> wrap >>>> around any of your application internals you would with to expose. >>>> >>> >>> >>> >> What kind of performance hit does this "wrapper" cause? A couple of my >>> app's instances take more than 4M transactions per day, up to several >>> hundred per second at peak times. So I can't afford much added work per >>> request. >>> >>> Thanks! >>> >>> >>> Hey David, >> >> Well, that depends what do you do for every transaction (request). In the >> above example with @WebListener, the app's performance should not be >> affected significantly, all it does it registers a JMX MBean at app >> deployment, and exposes the attributes and operations (getters/setters + >> other public methods) to JMX clients invoke this MBean. Once you undeploy >> the app, it unregisters the MBean. >> > > Ok, that sounds promising. I was worried that every request might have to > go through the filter/wrapper before getting to my core processing code. > If the MBean classes only need to make (for example) getCounter() calls > into my app's existing counters when needed, then that shouldn't be a > problem. > > > > >> Sure, performance will depend on how often you call JMX, and that might >> shave few OS cycles away from standard app operations (4M tx per day), if >> for example you want to make JMX calls every microsecond/second to plot >> some charts, etc... that might put a dent in your app performance. >> >> Few questions for you: >> - What kind of attributes/operations would you like to expose in your >> application, by using JMX? >> > > I am already keeping some counters and other information and exposing it > through a browser interface into each instance (a .jsp). But as the number > of instances has grown from 3 to 12, monitoring each instance's status has > become burdensome. Hence my desire to consolidate the monitoring of all > instances into a single location, and present the same information through > the new interface I'm discussing here. That data plus some startup > parameters (the location of each app's various resources mostly) are all > that I am looking to expose for now. > > > > - What would you like to manage using JMX? >> > > If by "managing", you mean controlling (changing settings, etc), I don't > plan on doing any of that. At least not for now. > > > > >> It would be great to get some performance metrics and see how that affects >> your application! >> >> Keep us posted :) >> >> Cheers! >> n. >> >> > > --------------------------------------------------------------------- > To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org > For additional commands, e-mail: users-h...@tomcat.apache.org > >
