0

We have a fairly simple Java SE standalone application that works as a scheduler. Each time it fires a new schedule a new Thread is created within which a new JDBC Connection is obtained from DriverManager.getConnection().

This has been running fine for many years. Then USN-2124-1 arrived and now, apparently at random, those Connections are hanging around for hundreds of seconds quickly exhausting the maximum number of MySQL connections allowed.

During one of these "incidents", I grabbed a thread dump via jstack which shows two of our schedule threads plus a very small number of threads that appear to be jvm housekeeping. So our own threads appear to have been garbage collected as expected.

If I also grabbed lsof output for the java process, and I see dozens of connections to MySQL. I am at a loss to explain how.

Can anyone offer suggestions?

Note: We also switched a test server across to MariaDB and observed the same sudden behaviour after a while.

jmkgreen
  • 1,633
  • 14
  • 22
  • do you explicitly close the connection when you are done with it? – Graham Griffiths Mar 07 '14 at 10:38
  • e.g. this answer says to close your resultset, statement and connection (in that order) in a finally block : http://stackoverflow.com/questions/2225221/closing-database-connections-in-java – Graham Griffiths Mar 07 '14 at 10:41
  • 2
    Why not pool connections? Opening new ones is a little hacky... – Boris the Spider Mar 07 '14 at 10:42
  • @BoristheSpider Because the scheduler application may get installed on a box without that database (and thus never calling that schedule) so everything is dynamically on demand. – jmkgreen Mar 07 '14 at 10:54
  • You can always lazy init the pool. They're very flexible. The issue is that if you open/close connections yourself you also need to manage their life cycle - making sure that they are properly closed; handling stale connections etc... Barely any enterprise applications handle connections manually. – Boris the Spider Mar 07 '14 at 10:59
  • @BoristheSpider I tried plugging in c3p0 as a DataSource on a static field within the schedule's Thread sub-class. I immediately hit on InterruptedException as it fired things up, so I had to pull it. – jmkgreen Mar 07 '14 at 11:03
  • @GrahamGriffiths I think the original code authors relied on http://docs.oracle.com/javase/6/docs/api/java/sql/Connection.html#close() where it states resources will be automatically released (which infers garbage collection). Indeed under normal circumstances that occurs. Following this security update the process appears to randomly fail miserably. – jmkgreen Mar 07 '14 at 11:05
  • I would try explicitly closing the connections. It's always dangerous to rely on timing of finalizer calls e.g. answere here : http://stackoverflow.com/questions/2983685/jdbc-does-the-connection-break-if-i-lose-reference-to-the-connection-object – Graham Griffiths Mar 07 '14 at 11:12

0 Answers0