NumberFormatException on initializePropsFromServer

[maydox]

Our mysql 4.1 DB recently hit the maximum number of allowed connections, immediate effects were that replication began to fail and our Java apps running through tomcat could no longer establish connections (even after more became available).

Here is the stack trace (using mysql-connector-java-5.0.5.jar):

java.lang.NumberFormatException
MESSAGE: For input string: ""

STACKTRACE:
java.lang.NumberFormatException: For input string: ""
at java.lang.NumberFormatException.forInputString(NumberFormatException.java:48)
at java.lang.Integer.parseInt(Integer.java:468)
at java.lang.Integer.parseInt(Integer.java:497)
at com.mysql.jdbc.Connection.initializePropsFromServer(Connection.java:4031)
at com.mysql.jdbc.Connection.createNewIO(Connection.java:2756)
at com.mysql.jdbc.Connection.<init>(Connection.java:1553)
at com.mysql.jdbc.NonRegisteringDriver.connect(NonRegisteringDriver.java:266)
at org.apache.tomcat.dbcp.dbcp.DriverConnectionFactory.createConnection(DriverConnectionFactory.java:37)
at org.apache.tomcat.dbcp.dbcp.PoolableConnectionFactory.makeObject(PoolableConnectionFactory.java:290)
at org.apache.tomcat.dbcp.dbcp.BasicDataSource.validateConnectionFactory(BasicDataSource.java:877)
at org.apache.tomcat.dbcp.dbcp.BasicDataSource.createDataSource(BasicDataSource.java:851)
at org.apache.tomcat.dbcp.dbcp.BasicDataSource.getConnection(BasicDataSource.java:540)

...

What is puzzling is that the PHP applications continued to function while the driver continued to throw this stack trace.  Tomcat was only able to reestablish a connection through the connector after the db was restarted.  

Has anyone seen this type of behavior before?  I searched the bug database and this archive and haven't seen anything quite like this.

[maydox]

Here are the likely offenders from the Connection source:

this.netBufferLength = Integer.parseInt((String) this.serverVariables.get("net_buffer_length"));

this.maxAllowedPacket = Integer.parseInt((String) this.serverVariables.get("max_allowed_packet"));

The code is clearly not ready for the server to return "" for these variables.

maydox wrote:

Our mysql 4.1 DB recently hit the maximum number of allowed connections, immediate effects were that replication began to fail and our Java apps running through tomcat could no longer establish connections (even after more became available).

Here is the stack trace (using mysql-connector-java-5.0.5.jar):

java.lang.NumberFormatException
MESSAGE: For input string: ""

STACKTRACE:
java.lang.NumberFormatException: For input string: ""
at java.lang.NumberFormatException.forInputString(NumberFormatException.java:48)
at java.lang.Integer.parseInt(Integer.java:468)
at java.lang.Integer.parseInt(Integer.java:497)
at com.mysql.jdbc.Connection.initializePropsFromServer(Connection.java:4031)
at com.mysql.jdbc.Connection.createNewIO(Connection.java:2756)
at com.mysql.jdbc.Connection.<init>(Connection.java:1553)
at com.mysql.jdbc.NonRegisteringDriver.connect(NonRegisteringDriver.java:266)
at org.apache.tomcat.dbcp.dbcp.DriverConnectionFactory.createConnection(DriverConnectionFactory.java:37)
at org.apache.tomcat.dbcp.dbcp.PoolableConnectionFactory.makeObject(PoolableConnectionFactory.java:290)
at org.apache.tomcat.dbcp.dbcp.BasicDataSource.validateConnectionFactory(BasicDataSource.java:877)
at org.apache.tomcat.dbcp.dbcp.BasicDataSource.createDataSource(BasicDataSource.java:851)
at org.apache.tomcat.dbcp.dbcp.BasicDataSource.getConnection(BasicDataSource.java:540)

...

What is puzzling is that the PHP applications continued to function while the driver continued to throw this stack trace.  Tomcat was only able to reestablish a connection through the connector after the db was restarted.  

Has anyone seen this type of behavior before?  I searched the bug database and this archive and haven't seen anything quite like this.

[Mark Matthews]

>
> Here are the likely offenders from the Connection source:
>
> this.netBufferLength = Integer.parseInt((String)
> this.serverVariables.get("net_buffer_length"));
>
> this.maxAllowedPacket = Integer.parseInt((String)
> this.serverVariables.get("max_allowed_packet"));
>
> The code is clearly not ready for the server to return "" for these
> variables.

Madox,

Interesting. I've _never_ seen the server return "" for those variables,
and it's not ever supposed to return "" for those variables, which is why
there's no defensive code around that. I suppose the driver could "punt"
when it runs into this situation, but I smell a memory overwrite condition
somwehere in the server.

Is this issue reproducible?

   -Mark

--
MySQL Java Mailing List
For list archives: http://lists.mysql.com/java
To unsubscribe:    http://lists.mysql.com/java?unsub=lists@...

[maydox]

Madox,

Interesting. I've _never_ seen the server return "" for those variables,
and it's not ever supposed to return "" for those variables, which is why
there's no defensive code around that. I suppose the driver could "punt"
when it runs into this situation, but I smell a memory overwrite condition
somwehere in the server.

Is this issue reproducible?

   -Mark

Hello Mark thank you for the reply.  No unfortunately we have not been able to reproduce this.  The DB is being upgraded from 4 to 5 so we may not see this issue again.  I have not seen this issue reported anywhere else but it may not be a bad idea anyway to put some "defense" around the code that retrieves those variables?

Regards,
Maydox

[Mark Matthews]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

maydox wrote:

>
>
>> Madox,
>>
>> Interesting. I've _never_ seen the server return "" for those variables,
>> and it's not ever supposed to return "" for those variables, which is why
>> there's no defensive code around that. I suppose the driver could "punt"
>> when it runs into this situation, but I smell a memory overwrite condition
>> somwehere in the server.
>>
>> Is this issue reproducible?
>>
>>    -Mark
>>
>
> Hello Mark thank you for the reply.  No unfortunately we have not been able
> to reproduce this.  The DB is being upgraded from 4 to 5 so we may not see
> this issue again.  I have not seen this issue reported anywhere else but it
> may not be a bad idea anyway to put some "defense" around the code that
> retrieves those variables?
>
> Regards,
> Maydox

Hi Maydox,

See http://lists.mysql.com/commits/34790 and
http://lists.mysql.com/commits/34791

This fix will end up in 5.0.8, and 5.1.4.

        -Mark
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.6 (MingW32)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD8DBQFHAsf9tvXNTca6JD8RApBnAKCiv+vzanxPZwLhzmy1x4YxYX1rAACeN9xl
Y7NYVV/E9UKb/Fxxbf+7B7I=
=Z38m
-----END PGP SIGNATURE-----

--
MySQL Java Mailing List
For list archives: http://lists.mysql.com/java
To unsubscribe:    http://lists.mysql.com/java?unsub=lists@...