-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 Shawn,
On 3/28/18 4:42 PM, Shawn Heisey wrote: > On 3/28/2018 1:18 PM, Christopher Schultz wrote: >>> I would like to write a logging thread that can get ALL of the >>> datasource objects from the context, and for types that it >>> knows, cast them to the appropriate object to log the >>> active/idle connection counts. >> >> It might be easier to do this via JMX. > > Perhaps. But then I have to figure out how to get the program > started with the sysprops that enable remote JMX. The system has > no GUI, and we don't have any X-Windows infrastructure, so running > JDK tools locally on the Linux server is challenging. Not > impossible, just requires me to set up things that I don't already > have, to do X forwarding over SSH. With the logging thread idea, we > just need to update code, recompile, and redeploy. I don't bother with any of that garbage. I use Tomcat's Manager application and the JMXProxyServlet. It's an HTTP-to-JMX bridge, so your client just has to speak HTTP. I use it along with a Nagios plug-in to fetch things like (wait for it) DataSource pool stats :) >> Since you already have a compile-time dependency upon Tomcat, >> there's no need to do class-name matching. Instead, just use >> "instanceof" as before: > > I did the code that way so that I can handle any type of > DataSource object, even if we change our pool configurations, just > by adding stanzas to the switch. And the default case logs the > class name if it's not handled explicitly, so I know what to add or > change. I went looking for a way to write a switch statement that > utilizes instanceof, didn't find anything. You're right, you can't. But string-comparisons are fragile. You may also run into ClassLoader problems where BasicDataSource (as loaded by your ClassLoader) != BasicDataSource (as instantiated by Tomcat). >> Instead of running a single thread that goes to sleep, maybe >> consider using a ScheduledExecutorService with a simpler runnable >> object that just logs the status a single time. > > Sounds like a good idea. That I have absolutely no idea how to > implement. I used the hammer I know. :) :) Have a look. It will probably be (slightly) more efficient than the code you wrote, and hey, you'll have less code to babysit. It also gives you trivial "shutdown" semantics... >> Don't forget to terminate the thread (or ExecutorService) when >> the application is shutting-down, of you'll have a ClassLoader >> (and a a huge memory) leak. > > I did think about that, but I wasn't sure how to detect a shutdown. > Is there something available that handles it easily and reliably > with only a small code change? Just now, I found the following > page when I went looking for how to detect that (independent of the > JVM shutting down): > > http://www.deadcoderising.com/execute-code-on-webapp-startup-and-shutd own-using-servletcontextlistener/ A > ServletContextListener is the way to go. In fact, you should probably be using a ServletContextListener to *launch* this thread in the first place. So, in your init() method, create+launch the thread (or ExecutorService), and in the destroy() method, shut it all down. > I think I could use this to create the thread on application > startup as well as making sure it shuts down cleanly. It would > mean that I can just create a new class for one of our applications > and edit a config file, instead of monkeying with other people's > code. That's the idea. > It's very encouraging to me that you picked up on the lack of > shutdown handling. It means I've got more than a sliver of your > attention! :) - -chris -----BEGIN PGP SIGNATURE----- Comment: GPGTools - http://gpgtools.org Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQIzBAEBCAAdFiEEMmKgYcQvxMe7tcJcHPApP6U8pFgFAlq9DawACgkQHPApP6U8 pFgLQRAAu5cfpWcgkL7Di/HHuot5r+Hi7XL6PAPbi28GYiVbszLfh3QRaZVhcFx4 AANpVYs4n0y5W1sJZzG8lXdvokm3dY00zWkLTOzU9MW7kuh0b8eV3RXwlyA7dBcz U+ndeU5o6iqvK7w6Z3kDHvSYbl28YEKz1Ff8SmdQ+GlEUOCSC9OcJlNoQ+dgpSAS LGW20RHvhk1+j7au4ebMBZpvyh6rsUSdbTt0s6xbqE7raoYPUgQZS2ZmB9iHgGP5 o20Rgaf7F2MQ+LzDBg2uJPMvH0x5QUb3FrDJGgQCRfVJwqeSPruF4lUmS8cktVpK CHOO/x6MXOGidbrFCBqcq7HN66UnJGVjK0bf/F/wU9RYjnAa9oT12Tn1mxGbP5Qr 8FiSmfA249j+DiMa57vQwD9SUS15V4Npm+sW2+2eamyG5tFbFfv7W/ZKjwzOwQBW 1tkyseCd4BBYPr1yksfvA2+eAE0s0Feamxt4+tF6x/0BZ0l/FA+aN8ZTSfcvM0Dh 5AyRPCJSIY8OpM+86Lk+LBo/hjJVuSiX99cQwb+mPMh9OZLKex8svHUqrJEr4si3 AB+eXA9LtfWWw5UqirXSdx4/oBCZCnegbOp2bw3DYnx8dZyGHTCsUoLkmFzVp4fP QPbS8WSZVKjqSHIuWvsuhosHH47AsjUpoTE1zX9PJy6lbnZ9RGk= =OtLy -----END PGP SIGNATURE----- --------------------------------------------------------------------- To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
