Java: DB Communications Link Failure

Question

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;
}

Answer 1

This is a wrapped exception and not really interesting. It is the root cause of the exception which actually tells us something about the root cause. Please look a bit further in the stacktrace. The chance is big that you'll then face a SQLException: Connection refused or SQLException: Connection timed out.

If this is true in your case as well, then all the possible causes are:

1. IP address or hostname in JDBC URL is wrong.
2. Hostname in JDBC URL is not recognized by local DNS server.
3. Port number is missing or wrong in JDBC URL.
4. DB server is down.
5. DB server doesn't accept TCP/IP connections.
6. Something in between Java and DB is blocking connections, e.g. a firewall or proxy.

To solve the one or the either, follow the following advices:

1. Verify and test them with ping.
2. Refresh DNS or use IP address in JDBC URL instead.
3. Verify it based on my.cnf of MySQL DB.
4. Start it.
5. Verify if mysqld is started without the --skip-networking option.
6. Disable firewall and/or configure firewall/proxy to allow/forward the port.

By the way (and unrelated to the actual problem), you don't necessarily need to load the JDBC driver on every getConnection() call. Just only once during startup is enough.

Answer 2

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?

Answer 3

As BalusC mentioned, it would be very useful to post the full stacktrace (always post a full stacktrace, it is useless and frustrating to have only the first lines of a stacktrace).

Anyway, you mentioned that your code was working fine and that this problem started suddenly to occur without any code change so I'm wondering if this could be related to you other question Problem with not closing db connection while debugging? Actually, if this problem started while debugging, then I think it is (you ran out of connections). In that case, restart you database server (and follow the suggestions of the other question to avoid this situation).