-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256
Henning,
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
> com.mysql.jdbc.ResultSetImpl.next(ResultSetImpl.java:7009) at
> com.server.persistence.state.connectors.jdbc.JDBCCleanupStateConnector.getUUIDsByTable(JDBCCleanupStateConnector.java:140)
>
>
... 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 ResultSet.next() 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 ( rs.next() )
> { //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 ResultSet.next might fail.
Let us know how it goes.
- -chris
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.14 (Darwin)
Comment: GPGTools - http://gpgtools.org
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/
iQIcBAEBCAAGBQJSVt4eAAoJEBzwKT+lPKRYt3EP/2iwF06+k4PeXATa8yUaSGJy
Ip5bEzb29qxn0VW3yPO9BvEnRsH5p8GLclqEbyd/S9qJuHfCWpf7BrnzQi68zQzC
4dadOY9kx+MtAzQeuvR0thBsOOwZLZHWaCkNZrwbuYrHX72vrbsa7jWfSVycXI8O
EQ1xJiEkzTJNYgI4rQ2SLc8Z0oj+86lzM+4Lpu3zoDX1i6CQclhgqKOeaa1fHhQW
HD75qI1hhyeWpwZRTDH9vsxmDO0W0S6LmxJNfxemlMhIv/MUrk4sSlA5rLsNqpyY
I0WIOAw5nxUHqXUmnd0flRIgLIBwieddmPZxXGXQgAzncgaWF90kpd9m5Rh3ty/G
mPKx98+EKlAJxaVUCczsyqGoTHBurFC6e6wav0aHek7fwUHZRfiqWJ0tsFeneiMP
Im+Sah3G2NBMahKw3TNcugkL+3aPgeDN48mgY2qgBE1c1mbbCNhnRbtZgTnQh3MF
zj+HKy2nvjExSpKAZttgad6HgEcHNP5e5rjUrLs9Mmax52HsN3ghn1qHmBylDRTy
E0b74EFNsDDJ1XH+k0olaqHrfhGIrQLihD8Jlu/gNhbKrNkJzIubGIsf7uvtS7KF
ksSxIyndIvNnQk4+9bX7zmK2ZPWACh8efbOFH6DcXXlHf/juxJYSnp4x3fHbdxIf
apaiMEQhUI68N+zaRl4b
=3Xdw
-----END PGP SIGNATURE-----
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org
