tomcat-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Christopher Schultz <>
Subject Re: NPE in using tomcat jdbc pool
Date Thu, 10 Oct 2013 17:04:30 GMT
Hash: SHA256


On 10/10/13 10:01 AM, Henning Rohlfs wrote:
> I've been trying to figure this problem out for some time now and
> I'm totally stuck. The Exception in question is the following: 
> Caused by: java.lang.NullPointerException at
> at 
> com.server.persistence.state.connectors.jdbc.JDBCCleanupStateConnector.getUUIDsByTable(
... 8 more

Looks like a bug in Connector/J. Are you up-to-date?

> It occurs very infrequently (and unfortunately I have not been able
> to reproduce it yet). I have also checked all occurences of
> getConnection(). Every one of them is wrapped (like below) by try
> {} finally {if (con != null) con.close();}. Connections are not
> stored locally and used by other threads later as far as I can tell
> either. The last time this problem occured, the thread in question
> was actually stuck for 10 minutes (as far as I reconstruct) before
> the NPE was thrown. During this time, the thread was seemingly
> stuck on SocketInputStream.socketRead0 (see below for stack trace),
> even though I set the sockettimeout when creating the db pool.

The connection pool probably gave-up on the connection and possibly
closed it. In that case, calling might have confused
Connector/J's implementation because the ResultSet should have been
killed by then.

> @Override public List<String> getUUIDsByTable( final String table)
> throws TableNotFoundException { Connection connection = null; try
> { connection = stateDbIo.getConnection(); final PreparedStatement
> ps = connection.prepareStatement( "SELECT uuid FROM `" + table+ "`
> GROUP BY uuid" ); final ResultSet rs = ps.executeQuery(); final
> List<String> result = new ArrayList<String>(); while ( )
> { //this is where the exception is thrown result.add( rs.getString(
> UUID_COLUMN ) ); } return result; } catch ( final Exception e ) { 
> throw new TableNotFoundException( table, e ); } finally { if (
> connection != null ) { try { connection.close(); } catch ( final
> SQLException e ) { // ignore } } } }

Don't forget to close your PreparedStatement and ResultSet objects.
Yes, I know that the JDBC spec says that closing the Connection should
close the associated objects (i.e. statement, result set), but in a
pooled situation, sometimes the JDBC specs break down a bit and
drivers (and pools) don't always follow things to the letter.

> I'm using the tomcat jdbc database pool (7.0.42) to get the
> connections.
> stateDbIo.getConnection(): public Connection getConnection() throws
> SQLException { if ( dataSource != null ) { final Connection
> connection = dataSource.getConnection(); connection.setReadOnly(
> readOnly ); connection.setAutoCommit( true ); return connection; }

It would be better to set the read-only and auto-commit flags based
upon the defaultAutoCommit and defaultReadOnly attributes of the pool
you configure. Then you don't have to worry about them ;)

I would guess that this is a MySQL Connector/J bug and not your fault.
That doesn't mean it's not your problem, though ;)

It sounds like you've done enough research to determine the problem
(timeout) so maybe you can create a small test-case that reproduces
it? I don't think it's got anything to do with Tomcat or tomcat-jdbc.
You should be able to rig-up a test case with a simple Java program
that connects to MySQL, then issues a long-running query (e.g. SELECT
SLEEP(10)) while the driver's timeout time is something less than 10
seconds. That should cause a disconnect during the query execution,
and subsequently calling might fail.

Let us know how it goes.

- -chris
Version: GnuPG v1.4.14 (Darwin)
Comment: GPGTools -
Comment: Using GnuPG with Thunderbird -


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

View raw message