This question already has an answer here:
My program that connects to a MySQL database was working fine. Then, without changing any code used to set up the connection, I get this exception:
com.mysql.jdbc.exceptions.jdbc4.CommunicationsException: Communications link failure
The last packet sent successfully to the server was 0 milliseconds ago. The driver has not received any packets from the server.
What happened?
The code used to get the connection:
private static Connection getDBConnection() throws SQLException, InstantiationException, IllegalAccessException, ClassNotFoundException {
String username = "user";
String password = "pass";
String url = "jdbc:mysql://www.domain.com:3306/dbName?connectTimeout=3000";
Class.forName("com.mysql.jdbc.Driver");
Connection conn = DriverManager.getConnection(url, username, password);
return conn;
}
I encountered same problem. I am using spring & dbcp & mysql 5.5But If I change
localhost
to192.168.1.110
then everything works. What make things more weird ismysql -h localhost
just works fine.update: Finally found a solution. Changing bindaddress to
localhost
or127.0.0.1
inmy.conf
will fix the problem.I had the same problem and I used most of the params (autoreconnect etc..), but didn't try the (test_on_idle, or test_on_connect) , I am going to do them next.
However, I had this hack that got me through this:
I have a cron job called Healthcheck, It wakes up every 10 mins and makes a REST API call to the server. The web / app server picks this up, connects to the db, makes a small change and comes back with a 'yes all quiet on western front' or 'shitshappening'. When the latter, it sends a pager / email to the right people.
It has the side effect of always keeping the db connection pool fresh. So long as this cron is running, I don't have the db connection timeout issues. otherwise, they crop up.
I got the same error but then I figured it out its because the Mysql server is not running at that time.
So to change the status of the server
Hope this will help.
In my case, the mysql.com downloaded Connector/J 5.1.29 .jar had this error whereas the 5.1.29 .jar downloaded from the MvnRepository did not.
This happened when building a Google appengine application in Android Studio (gradle, Windows x64), communicating to a Linux MySQL server on the local network/local VM.
We have a piece of software (webapp with Tomcat) using Apache commons connection pooling, and worked great for years. In the last month I had to update the libraries due to an old bug we were encountering. The bug had been fixed in a recent version.
Shortly after deploying this, we started getting exactly these messages. Out of the thousands of connections we'd get a day, a handful (under 10, usually) would get this error message. There was no real pattern, except they would sometimes cluster in little groups of 2 to 5.
I changed the options to on the pool to validate the connection every time one is taken from or put back in the pool (if one is found bad, a new one is generated instead) and the problem went away.
Have you updated your MySQL jar lately? It seems like there may be a new setting that didn't used to be there in our (admittedly very old) jar.
I agree with BalusC to try some other options on your config, such as those you're passing to MySQL (in addition to the connection timeout).
If this failure is transient like mine was, instead of permanent, then you could use a simple try/catch and a loop to keep trying until things succeed or use a connection pool to handle that detail for you.
Other random idea: I don't know what happens why you try to use a closed connection (which exception you get). Could you be accidentally closing the connection somewhere?
I got the communications failure error when using a java.sql.PreparedStatement with a specific statement.
This was running against MySQL 5.6, Tomcat 7.0.29 and JDK 1.7.0_67 on a Windows 7 x64 machine.
The cause turned out to be setting an integer to a string parameter and a string to an integer parameter then trying to perform executeQuery on the prepared statement. After I corrected the order of parameter setting the statement performed correctly.
This had nothing to do with network issues as the wording of the error message suggested.