-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 David,
On 5/19/14, 8:42 AM, David kerber 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. This is entirely up to you and your requirements. For instance, if you need to update some stats with every transaction, then yes you'll probably need to take a bit of a performance hit to execute the code to do such work. If you already have whatever information you want to be made available via JMX, then all you have to do it fetch it each time someone requests the data (e.g. no additional work per transaction). - -chris -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 Comment: GPGTools - http://gpgtools.org Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQIcBAEBCAAGBQJTen1kAAoJEBzwKT+lPKRYFBMP/ju6liFYRz0ofwH8zTciz4i+ t6sJ6gvmEZCraXnuCCClGW+geMQhRvTzv6v/PaCvZQW0/rmY/UQCreW1Yk1EaFw/ bWFnqFHSz9K7QJjiYpEe9aKBmUlOnGy0TFT21mrC5mpXUdz2YpVUl6CK/0Kbj5c7 NmUZ2R3rn7Vg4J1Dk0yglz03bQzIcRzwR0lD+mLyR9rduTyF3hidCiEKZ5uIIcqR yHEr8cCk6lW/YKkt0c+5fLzez0842FXJR/tjU+cO/T/HM44d0bPZDV+4d9vYBQm2 DBX8u3DWvNF8Gh9EpzpMatFkjLpofusu2TzX9v67cxKXoSrUnRPWIhww/lCmfFP/ bv9ZXWLkYRouB0uAWhuLvMEOz6aLfeHcIRDH+92GhpVbwXwzreahHmDBx13sakqK N3or7l1afcL66axw+tcYefuiDvOV8SO/clRUwc5XtfAv2CWBaPTqxbaMcJ7u9EOQ ygp0+I7IZ62kYPeJ2PKwOx4RC0IQtTKYeE67d79xChTDPU30UWvZiFObKuozrDfM /7BMD+iO145RyjXYoPjjOqY9kbQqTBHqqqOB0e2+slPJivz93DmAqmTws9/5J3I1 N4SGSH094pTfsb7NMmsr5JmoASJNRcaBRjDE7UtR5zP83eUX3UeFfnvPaYeuXJbo O8xxdCMNkZBagpBs4c/V =jUCP -----END PGP SIGNATURE----- --------------------------------------------------------------------- To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
