RE: Connector/J 3.0.9 Unexpected end of input
Thanks. Yeah I saw the section on failover. I guess I didn't understand that autoreconnect in the url is now used for failover to another server rather than reconnecting to the same server. Is that what you mean? If that's the case I can move to dbcp or something that should handle stale connections. -Original Message- From: Mark Matthews [mailto:[EMAIL PROTECTED] Sent: Thursday, December 18, 2003 12:34 PM To: Bill Ataras Cc: [EMAIL PROTECTED] Subject: Re: Connector/J 3.0.9 Unexpected end of input -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Bill Ataras wrote: I upgraded to Connector/J 3.09 from 2.0.14. After some hours, the driver looses it's connection and will not reconnect (despite setting reconnect=true). The error starts as follows below. I rollback to 2.0.14 and everything is stable again. This is using mysql 4.0.16-standard. Is connector/j 3.0x production release? Yes, Connector/J 3.0.x is a production release. Perhaps you missed the following information in the README that deals with the fact that autoReconnect=true behavior has changed? The driver now has fail-over support. This allows the driver to fail-over to any number of slave hosts and still perform read-only queries. Fail-over only happens when the connection is in a autoCommit(true) state, because fail-over can not happen reliably when a transaction is in progress. Most good application servers and connection pools set autoCommit to 'true' at the end of every transaction/connection use. I need to re-work the docs to say that this applies to autoReconnect as well, however, the following troubleshooting section from the README also tells you how to handle this (and why relying on autoReconnect might not be a good idea for most people): Issue: I have a servlet/application that works fine for a day, and then stops working overnight. Resolution: MySQL closes connections after 8 hours of inactivity. You either need to use a connection pool that handles stale connections or use the autoReconnect parameter (see USAGE AND INSTALLATION). Also, you should be catching SQLExceptions in your application and dealing with them, rather than propagating them all the way until your application exits, this is just good software development. MySQL Connector/J will set the SQLState (see java.sql.SQLException.getSQLState() in your APIDOCS) to 08S01 when it encounters network-connectivity issues during the processing of a query. Your application code should then attempt to re-connect to MySQL at this point. Regards, -Mark - -- Mr. Mark Matthews MySQL AB, Software Development Manager, J2EE and Windows Platforms Office: +1 708 557 2388 www.mysql.com Are you MySQL Certified? http://www.mysql.com/certification/ -BEGIN PGP SIGNATURE- Version: GnuPG v1.2.3 (MingW32) Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org iD8DBQE/4g9RtvXNTca6JD8RAtRGAJ9IkWznogxvmoFfFVdqtWsMMHCV0gCfYL/0 otNjauYKCQn98p5oOvM/uzo= =NUmy -END PGP SIGNATURE- -- MySQL General Mailing List For list archives: http://lists.mysql.com/mysql To unsubscribe:http://lists.mysql.com/[EMAIL PROTECTED]
Re: Connector/J 3.0.9 Unexpected end of input
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Bill Ataras wrote: Thanks. Yeah I saw the section on failover. I guess I didn't understand that autoreconnect in the url is now used for failover to another server rather than reconnecting to the same server. Is that what you mean? If that's the case I can move to dbcp or something that should handle stale connections. If you only have one host listed, autoReconnect attempts to fail-over back to the same host (just like before). The change is in the semantics of _when_ reconnect can happen. It is really only safe to reconnect when you are not in a transaction (and even then, it could be risky if it happens at an inoportune time, which only _your_ application can deduce, not the driver). That's why the driver now _requires_ autoCommit to be 'true' to be able to reconnect. It's also why I've been recommending for over a year or so now (check the mailing list archives, or even the 'Troubleshooting' section of the README), that developers should really be handling this case themselves (i.e. stale connection), because only they have the knowledge of their application that allows them to determine what is the correct action to take to recover a 'stale' connection. Regards, -Mark - -- Mr. Mark Matthews MySQL AB, Software Development Manager, J2EE and Windows Platforms Office: +1 708 557 2388 www.mysql.com Are you MySQL Certified? http://www.mysql.com/certification/ -BEGIN PGP SIGNATURE- Version: GnuPG v1.2.3 (MingW32) Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org iD8DBQE/4x34tvXNTca6JD8RAtzLAKCDqzcU/p0VIaxR9okz7/t2+VsryQCfR3wW lvkGVCFVjOAWINWnu8PSMYA= =T5p6 -END PGP SIGNATURE- -- MySQL General Mailing List For list archives: http://lists.mysql.com/mysql To unsubscribe:http://lists.mysql.com/[EMAIL PROTECTED]
Re: Connector/J 3.0.9 Unexpected end of input
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Bill Ataras wrote: I upgraded to Connector/J 3.09 from 2.0.14. After some hours, the driver looses it's connection and will not reconnect (despite setting reconnect=true). The error starts as follows below. I rollback to 2.0.14 and everything is stable again. This is using mysql 4.0.16-standard. Is connector/j 3.0x production release? Yes, Connector/J 3.0.x is a production release. Perhaps you missed the following information in the README that deals with the fact that autoReconnect=true behavior has changed? The driver now has fail-over support. This allows the driver to fail-over to any number of slave hosts and still perform read-only queries. Fail-over only happens when the connection is in a autoCommit(true) state, because fail-over can not happen reliably when a transaction is in progress. Most good application servers and connection pools set autoCommit to 'true' at the end of every transaction/connection use. I need to re-work the docs to say that this applies to autoReconnect as well, however, the following troubleshooting section from the README also tells you how to handle this (and why relying on autoReconnect might not be a good idea for most people): Issue: I have a servlet/application that works fine for a day, and then stops working overnight. Resolution: MySQL closes connections after 8 hours of inactivity. You either need to use a connection pool that handles stale connections or use the autoReconnect parameter (see USAGE AND INSTALLATION). Also, you should be catching SQLExceptions in your application and dealing with them, rather than propagating them all the way until your application exits, this is just good software development. MySQL Connector/J will set the SQLState (see java.sql.SQLException.getSQLState() in your APIDOCS) to 08S01 when it encounters network-connectivity issues during the processing of a query. Your application code should then attempt to re-connect to MySQL at this point. Regards, -Mark - -- Mr. Mark Matthews MySQL AB, Software Development Manager, J2EE and Windows Platforms Office: +1 708 557 2388 www.mysql.com Are you MySQL Certified? http://www.mysql.com/certification/ -BEGIN PGP SIGNATURE- Version: GnuPG v1.2.3 (MingW32) Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org iD8DBQE/4g9RtvXNTca6JD8RAtRGAJ9IkWznogxvmoFfFVdqtWsMMHCV0gCfYL/0 otNjauYKCQn98p5oOvM/uzo= =NUmy -END PGP SIGNATURE- -- MySQL General Mailing List For list archives: http://lists.mysql.com/mysql To unsubscribe:http://lists.mysql.com/[EMAIL PROTECTED]
Connector/J 3.0.9 Unexpected end of input
I upgraded to Connector/J 3.09 from 2.0.14. After some hours, the driver looses it's connection and will not reconnect (despite setting reconnect=true). The error starts as follows below. I rollback to 2.0.14 and everything is stable again. This is using mysql 4.0.16-standard. Is connector/j 3.0x production release? Thanks java.sql.SQLException: Communication link failure: java.io.IOException, underlying cause: Unexpected end of input stream Stacktrace: java.io.IOException: Unexpected end of input stream
