Hello David, yes there is. And I sent you two links to blog entries about exactly that. Did you read them?
regards Leon P.S. in the examples the app specific info is monitored directly and not via jmx, because that saves a lot of overhead, but reading jmx beans is also supported. On Mon, May 19, 2014 at 3:01 PM, David kerber <dcker...@verizon.net> wrote: > On 5/19/2014 8:52 AM, Leon Rosenberg wrote: > >> 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/ >> > > Leon - > > I don't want to re-invent the wheel if there's already something that will > do what I need, but I don't see what you're getting at. Is there an > already-existing tool that will let me look into multiple identical but > independent tomcat apps, read various MBeans from each one and display that > data in a single window? The data I want to display is > application-specific, and not generic stuff like heap usage, GC info, etc. > > I understand that I should be able to connect to any one app and read its > MBeans with some standard JMX tool/interface, but that's essentially what > I'm doing now (though without using JMX) and am trying to get away from. > > Dave > > > > >> 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 >>> >>> >>> >> > > --------------------------------------------------------------------- > To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org > For additional commands, e-mail: users-h...@tomcat.apache.org > >
