tomcat-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Christopher Schultz <>
Subject Re: Getting all JDBC configs from the context
Date Thu, 29 Mar 2018 16:00:44 GMT
Hash: SHA256


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

>> 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):

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

Comment: GPGTools -
Comment: Using GnuPG with Thunderbird -


To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message