Debugging Communication Link Failure exceptions in Connector/J

Have you seen error messages similar to the following:

Communications link failure – Last packet sent to the server was X ms ago.

Judging from the forums, many people have had problems with this.  Here’s a brief overview of the causes, and potential solutions.

Generally speaking, this error suggests that the network connection has been closed. There can be several root causes:

  • Firewalls or routers may clamp down on idle connections (the MySQL client/server protocol doesn’t ping).
  • The MySQL Server may be closing idle connections which exceed the wait_timeout or interactive_timeout threshold

There’s a couple of useful diagnostic details which can be useful.  For starters, when a recent (5.1.13) version of Connector/J is used, you should see additional details around both the last packet sent and received.  Older versions may simply indicate the last time a packet was sent to the server, which is frequently zero ms ago.  That’s not terribly useful, and it may be that you just sent a packet, but haven’t received a packet from the server for 12 hours.  Knowing how long it’s been since Connector/J last received a packet from the server is useful information, so if you are not seeing this in your exception message, update your driver.

The second useful diagnostic detail shows up when Connector/J notices that the time a packet was last sent/received exceeds the wait_timeout or interactive_timeout threshold.  It will attempt to notify you of this in the exception message.

The following can be helpful in avoiding such problems, but ultimately network connections can be volatile:

  • Ensure connections are valid when checked out of connection pool (use query which starts with “/* ping */” *exactly* to execute lightweight ping instead of full query)
  • Minimize duration a Connection object is left idle while other application logic is executed
  • Explicitly validate Connection before using after being left idle for extended period of time
  • Ensure wait_timeout and interactive_timeout are set sufficiently high
  • Ensure tcpKeepalive is enabled
  • Ensure that any configurable firewall or router timeout setting accounts for maximum expected idle connection time.
  • Make sure that you are not setting socketTimeout, or that it is set to a sufficiently high value to avoid socket timeouts.

I’ve seen exception messages which indicate Connections being used after sitting idle for hours – sometimes days.  If you do this, make sure that you are explicitly testing the connection before using it after lengthy idle periods.  Network connections fail, and applications need to be prepared to handle that.  But expecting connections to survive extended periods where left idle and work magically when used again hours later is just asking for trouble.

[Update 11 August 2015]  Combinations of specific versions of MySQL Server, Connector/Java and JREs may produce “communication link failure” messages when trying to negotiate SSL/TLS during the connection phase.  Further details are found here.

4 thoughts on “Debugging Communication Link Failure exceptions in Connector/J

  1. Hello,

    We are using Hibernate to Connect to My SQL Data base.
    Our Application is deployed on Tomcat.

    After 5 hrs using the Application we are reeving the below Error.

    Any Suggestion would be highly appreciated

    org.hibernate.exception.JDBCConnectionException: Communications link failure

    The last packet successfully received from the server was 1,847,704 milliseconds ago. The last packet sent successfully to the server was 1,847,720 milliseconds ago.
    at org.hibernate.exception.internal.SQLStateConversionDelegate.convert(
    at org.hibernate.exception.internal.StandardSQLExceptionConverter.convert(
    at org.hibernate.engine.jdbc.spi.SqlExceptionHelper.convert(
    at org.hibernate.engine.jdbc.spi.SqlExceptionHelper.convert(
    at org.hibernate.engine.jdbc.internal.proxy.AbstractStatementProxyHandler.continueInvocation(
    at org.hibernate.engine.jdbc.internal.proxy.AbstractProxyHandler.invoke(
    at $Proxy30.executeQuery(Unknown Source)
    at org.hibernate.persister.entity.AbstractEntityPersister.getDatabaseSnapshot(
    at org.hibernate.engine.internal.StatefulPersistenceContext.getDatabaseSnapshot(
    at org.hibernate.engine.internal.ForeignKeys.isTransient(
    at org.hibernate.engine.internal.ForeignKeys$Nullifier.isNullifiable(
    at org.hibernate.engine.internal.ForeignKeys$Nullifier.nullifyTransientReferences(
    at org.hibernate.engine.internal.ForeignKeys$Nullifier.nullifyTransientReferences(
    at org.hibernate.action.internal.AbstractEntityInsertAction.nullifyTransientReferencesIfNotAlready(
    at org.hibernate.action.internal.EntityIdentityInsertAction.execute(
    at org.hibernate.engine.spi.ActionQueue.execute(
    at org.hibernate.engine.spi.ActionQueue.addResolvedEntityInsertAction(
    at org.hibernate.engine.spi.ActionQueue.addInsertAction(
    at org.hibernate.engine.spi.ActionQueue.addAction(
    at org.hibernate.event.internal.AbstractSaveEventListener.addInsertAction(
    at org.hibernate.event.internal.AbstractSaveEventListener.performSaveOrReplicate(
    at org.hibernate.event.internal.AbstractSaveEventListener.performSave(
    at org.hibernate.event.internal.AbstractSaveEventListener.saveWithGeneratedId(
    at org.hibernate.event.internal.DefaultSaveOrUpdateEventListener.saveWithGeneratedOrRequestedId(
    at org.hibernate.event.internal.DefaultSaveEventListener.saveWithGeneratedOrRequestedId(
    at org.hibernate.event.internal.DefaultSaveOrUpdateEventListener.entityIsTransient(
    at org.hibernate.event.internal.DefaultSaveEventListener.performSaveOrUpdate(
    at org.hibernate.event.internal.DefaultSaveOrUpdateEventListener.onSaveOrUpdate(
    at org.hibernate.internal.SessionImpl.fireSave(
    at com.tetrus.prea.server.aop.AuditActionInterceptor.invoke(
    at com.tetrus.prea.server.ApplicationServiceImpl$$EnhancerByGuice$$f80e7fea.getSearchResult()
    at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
    at sun.reflect.NativeMethodAccessorImpl.invoke(
    at sun.reflect.DelegatingMethodAccessorImpl.invoke(
    at java.lang.reflect.Method.invoke(
    at javax.servlet.http.HttpServlet.service(
    at javax.servlet.http.HttpServlet.service(
    at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(
    at org.apache.catalina.core.ApplicationFilterChain.doFilter(
    at org.apache.catalina.core.StandardWrapperValve.invoke(
    at org.apache.catalina.core.StandardContextValve.invoke(
    at org.apache.catalina.authenticator.AuthenticatorBase.invoke(
    at org.apache.catalina.core.StandardHostValve.invoke(
    at org.apache.catalina.valves.ErrorReportValve.invoke(
    at org.apache.catalina.valves.AccessLogValve.invoke(
    at org.apache.catalina.core.StandardEngineValve.invoke(
    at org.apache.catalina.connector.CoyoteAdapter.service(
    at org.apache.coyote.http11.AbstractHttp11Processor.process(
    at org.apache.coyote.AbstractProtocol$AbstractConnectionHandler.process(
    at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(
    at java.util.concurrent.ThreadPoolExecutor$
    Caused by: com.mysql.jdbc.exceptions.jdbc4.CommunicationsException: Communications link failure

    The last packet successfully received from the server was 1,847,704 milliseconds ago. The last packet sent successfully to the server was 1,847,720 milliseconds ago.
    at sun.reflect.GeneratedConstructorAccessor71.newInstance(Unknown Source)
    at sun.reflect.DelegatingConstructorAccessorImpl.newInstance(
    at java.lang.reflect.Constructor.newInstance(
    at com.mysql.jdbc.Util.handleNewInstance(
    at com.mysql.jdbc.SQLError.createCommunicationsException(
    at com.mysql.jdbc.MysqlIO.send(
    at com.mysql.jdbc.MysqlIO.sendCommand(
    at com.mysql.jdbc.MysqlIO.sqlQueryDirect(
    at com.mysql.jdbc.ConnectionImpl.execSQL(
    at com.mysql.jdbc.PreparedStatement.executeInternal(
    at com.mysql.jdbc.PreparedStatement.executeQuery(
    at com.mchange.v2.c3p0.impl.NewProxyPreparedStatement.executeQuery(
    at sun.reflect.GeneratedMethodAccessor27.invoke(Unknown Source)
    at sun.reflect.DelegatingMethodAccessorImpl.invoke(
    at java.lang.reflect.Method.invoke(
    at org.hibernate.engine.jdbc.internal.proxy.AbstractStatementProxyHandler.continueInvocation(
    … 62 more
    Caused by: Connection reset by peer: socket write error
    at Method)
    at com.mysql.jdbc.MysqlIO.send(
    … 72 more

    1. Hi Swakesh,

      The exception indicates that the connection was left idle for just over 30 minutes before the attempted operation, which failed because the network connection was closed. You can look for several root causes:

      1. Is socketTimeout set at all? If set to 30m or less, this would explain the behavior
      2. Do you receive other similar exceptions citing 30m or more in idle time? If so, maybe you have network infrastructure with corresponding timeouts
      3. If you have connection pooling enabled, have you configured maintenance operations properly so that connections in the pool (not checked out) are periodically validated? You will want to make sure that idle connections are validated more frequently than every 30m, based on this exception.
      4. If you have connection pooling enabled, you might consider validating the connection on check-out from the pool – if your library supports it. This will limit the opportunity for a connection to die between validation and application use (although you can never be 100% guaranteed that a validated connection will still work when the application actually goes to use it).

      I hope that helps! If you are using MySQL 5.6, you might also consider checking to see how idle your connections are.

  2. Hi Todd,

    Thank you very much for your Time and reply.

    I tried to set the idle connection time out to 300s.

    If still its not fixed, i will try other options mentioned in comment.


    1. Hi Swakesh,

      Glad to help – if that doesn’t solve the problem, check whether your connection pool library allows for validation before checkout. While that adds latency when obtaining a Connection from the pool (the application thread waits while the Connection is validated), it assures the highest probability that the Connection will be valid when the application starts to use it.

Leave a Reply

Your email address will not be published. Required fields are marked *

Time limit is exhausted. Please reload CAPTCHA.