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
