[2.0] Anybody else getting a MySQL communication link failure every so often?

[Drew Hamlett]

I have my app running locally and on heroku and it seems every so
often it errors out with a MySQL communication link failure.

This is just an example from heroku log.

2011-12-02T01:01:14+00:00 app[web.1]: [error] c.j.b.ConnectionHandle -
Database access problem. Killing off all remaining connections in the
connection pool. SQL State = 08S01
2011-12-02T01:01:14+00:00 app[web.1]: [error] application -
2011-12-02T01:01:14+00:00 app[web.1]:
2011-12-02T01:01:14+00:00 app[web.1]: ! @68i0mf77p - Internal server
error, for request [GET /equipment] ->
2011-12-02T01:01:14+00:00 app[web.1]:
2011-12-02T01:01:14+00:00 app[web.1]: play.core.Invoker$$anonfun
$receive$1$$anon$1: Execution exception [[CommunicationsException:
Communications link failure
2011-12-02T01:01:14+00:00 app[web.1]:
2011-12-02T01:01:14+00:00 app[web.1]: The last packet successfully
received from the server was 3,154,918 milliseconds ago. The last
packet sent successfully to the server was 7 milliseconds ago.]]
2011-12-02T01:01:14+00:00 app[web.1]: at play.core.Invoker$$anonfun
$receive$1.apply(Invoker.scala:54) [play_2.9.1-2.0-beta.jar:2.0-beta]
2011-12-02T01:01:14+00:00 app[web.1]: at play.core.Invoker$$anonfun
$receive$1.apply(Invoker.scala:40) [play_2.9.1-2.0-beta.jar:2.0-beta]
2011-12-02T01:01:14+00:00 app[web.1]: at akka.actor.Actor
$class.apply(Actor.scala:545) [akka-actor-1.2.jar:na]
2011-12-02T01:01:14+00:00 app[web.1]: at
play.core.Invoker.apply(Invoker.scala:37) [play_2.9.1-2.0-beta.jar:2.0-
beta]
2011-12-02T01:01:14+00:00 app[web.1]: at
akka.actor.LocalActorRef.invoke(ActorRef.scala:905) [akka-
actor-1.2.jar:na]
2011-12-02T01:01:14+00:00 app[web.1]: at
akka.dispatch.MessageInvocation.invoke(MessageHandling.scala:25) [akka-
actor-1.2.jar:na]
2011-12-02T01:01:14+00:00 app[web.1]: Caused by:
com.mysql.jdbc.exceptions.jdbc4.CommunicationsException:
Communications link failure
2011-12-02T01:01:14+00:00 app[web.1]:
2011-12-02T01:01:14+00:00 app[web.1]: The last packet successfully
received from the server was 3,154,918 milliseconds ago. The last
packet sent successfully to the server was 7 milliseconds ago.
2011-12-02T01:01:14+00:00 app[web.1]: at
sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native Method)
~[na:1.6.0_20]
2011-12-02T01:01:14+00:00 app[web.1]: at
sun.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:
57) ~[na:1.6.0_20]
2011-12-02T01:01:14+00:00 app[web.1]: at
sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:
45) ~[na:1.6.0_20]
2011-12-02T01:01:14+00:00 app[web.1]: at
java.lang.reflect.Constructor.newInstance(Constructor.java:532) ~[na:
1.6.0_20]
2011-12-02T01:01:14+00:00 app[web.1]: at
com.mysql.jdbc.Util.handleNewInstance(Util.java:411) ~[mysql-connector-
java-5.1.17.jar:na]
2011-12-02T01:01:14+00:00 app[web.1]: at
com.mysql.jdbc.SQLError.createCommunicationsException(SQLError.java:
1116) ~[mysql-connector-java-5.1.17.jar:na]
2011-12-02T01:01:14+00:00 app[web.1]: Caused by: java.io.EOFException:
Can not read response from server. Expected to read 4 bytes, read 0
bytes before connection was unexpectedly lost.
2011-12-02T01:01:14+00:00 app[web.1]: at
com.mysql.jdbc.MysqlIO.readFully(MysqlIO.java:2540) ~[mysql-connector-
java-5.1.17.jar:na]
2011-12-02T01:01:14+00:00 app[web.1]: at
com.mysql.jdbc.MysqlIO.reuseAndReadPacket(MysqlIO.java:2990) ~[mysql-
connector-java-5.1.17.jar:na]
2011-12-02T01:01:14+00:00 app[web.1]: at
com.mysql.jdbc.MysqlIO.reuseAndReadPacket(MysqlIO.java:2979) ~[mysql-
connector-java-5.1.17.jar:na]
2011-12-02T01:01:14+00:00 app[web.1]: at
com.mysql.jdbc.MysqlIO.checkErrorPacket(MysqlIO.java:3520) ~[mysql-
connector-java-5.1.17.jar:na]
2011-12-02T01:01:14+00:00 app[web.1]: at
com.mysql.jdbc.MysqlIO.sendCommand(MysqlIO.java:1990) ~[mysql-
connector-java-5.1.17.jar:na]
2011-12-02T01:01:14+00:00 app[web.1]: at
com.mysql.jdbc.MysqlIO.sqlQueryDirect(MysqlIO.java:2151) ~[mysql-
connector-java-5.1.17.jar:na]

If I refresh the page it works fine. It seems sporadic at this
point. I'm using Scala with Anorm. Thanks.

[Spike Washburn]

MySQL is notoriously finicky about having connections in a pool that
stay idle for too long. Ideally, you'd be able to configure your
app's connection pool to never use connections that have been idle for
longer than N-time (where N is less than the max mysql max idle time).

With Connection pools like DBCP, I typically suggest actively using
settings like testOnBorrow for applications that are idle for long
periods of time. I'm not sure what your app is using for it's
connection pooling, but some of the parameters found here may be worth
playing with if you are using Play's pools.

http://www.playframework.org/documentation/1.2.3/configuration#db.pool.maxIdleTimeExcessConnections

You can read more details about MySQL idle timeouts here [http://
wiki.cloudbees.com/bin/view/RUN/
DatabaseGuide#HAvoidingDatabaseIdleTimeouts]. The specific settings
in that article won't help for your app on Heroku, but the general
approach will work it you properly tune the connection pool you are
using.

[Daryl]

By default MySQL connections time out after being idle for 8 hours. We
found the best way around this was to create a c3p0.properties file in
app/conf.

c3p0.maxIdleTimeExcessConnections=1800
c3p0.maxIdleTime=3600
c3p0.maxConnectionAge=3600

This tells the pool how long to wait before dumping old and idle
connections.

thanks

Daryl.

[antman]

We also run into this problem. We added this snippet of error checking
code to reopen a closed connection:

if (DB.getConnection().isClosed())
{
((org.hibernate.ejb.EntityManagerImpl)
JPA.em()).getSession().reconnect(DB.getConnection());
}
If you know a worse case timeout, changing the Hibernate configuration
as suggested above is probably the best solution though.

[Drew Hamlett]

I'm sorry I mean't to put a 2.0 in my message. This post is regarding
Play 2.0. I've never had this error in 1.x. Thanks.

[Drew Hamlett]

Iss this related any way?

http://jolbox.com/forum/viewtopic.php?f=3&t=235

[Drew Hamlett]

Bump?

[oblivion]

I'm getting these errors as well, no solution in sight yet...

[Drew Hamlett]

Is this just a MySQL issue? If so I can switch to something else.
I'm trying to get this small application out the door.

[Drew Hamlett]

The connection pool doesn't seem to be keeping the connections up like
it did in Play 1.x.

[Blake Matheny]

The magic params I required on the JDBC connection string were:
?autoReconnect=true&interactiveClient=true

In my environment I needed to make sure the timeout applied was based
on the INTERACTIVE_TIMEOUT, not on the WAIT_TIMEOUT.

-Blake

> --
> You received this message because you are subscribed to the Google Groups "play-framework" group.
> To post to this group, send email to play-fr...@googlegroups.com.
> To unsubscribe from this group, send email to play-framewor...@googlegroups.com.
> For more options, visit this group at http://groups.google.com/group/play-framework?hl=en.
>

--
Blake Matheny
tumblr.mobocracy.net

[Drew Hamlett]

Well my MySQL Interactive_timeout is 8 hours, while my wait_timeout is
600 seconds. So using this flag I'll be good for 8 hours instead of
600 seconds. The problem seems to be after these timeouts occur the
connection is gone(obviously). That's when I'm getting the
exception. My 3 Play 1.x apps always have a connection open. It
never times out.

The connection counts to 10 then resets to 0...counts to 10 resets to
0. It's doing some kind of keep alive. While these Play 2.0
connections just keep counting up until there gone.

> > For more options, visit this group athttp://groups.google.com/group/play-framework?hl=en.
>
> --
> Blake Matheny
> tumblr.mobocracy.net

[Drew Hamlett]

I'm telling you guys the BoneCP plugin is broken at this point. It's
not correct. I have several Play 2.0 beta apps in my company already
as well as re-doing our web site.

ww is not typo(still in progress)

ww.atlanticpkg.com

I've made a C3P0 plugin and all the problems go away. With the BoneCP
the page takes a severe performance hit while getting a
connection(after idle) or even throws a Mysql com link error. With
C3P0 the connection is just like it was in Play 1.x, which is
perfect. I have tested this on many mysql databases configured
differently. It's the same story every time.

I hope this can be fixed.

On Jan 10, 12:02 pm, Drew Hamlett <drewhj...@gmail.com> wrote:
> Well my MySQL Interactive_timeout is 8 hours, while my wait_timeout is
> 600 seconds.  So using this flag I'll be good for 8 hours instead of
> 600 seconds.  The problem seems to be after these timeouts occur the
> connection is gone(obviously).  That's when I'm getting the
> exception.  My 3 Play 1.x apps always have a connection open.  It
> never times out.
>
> The connection counts to 10 then resets to 0...counts to 10 resets to
> 0.  It's doing some kind of keep alive.  While these Play 2.0
> connections just keep counting up until there gone.
>
> On Jan 10, 10:26 am, Blake Matheny <bmath...@tumblr.com> wrote:
>
>
>
>
>
>
>
> > The magic params I required on the JDBC connection string were:
> > ?autoReconnect=true&interactiveClient=true
>
> > In my environment I needed to make sure the timeout applied was based
> > on the INTERACTIVE_TIMEOUT, not on the WAIT_TIMEOUT.
>
> > -Blake
>

> > On Tue, Jan 10, 2012 at 9:34 AM,DrewHamlett<drewhj...@gmail.com> wrote:
> > > Bump?
>

> > > On Dec 3 2011, 10:38 pm,DrewHamlett<drewhj...@gmail.com> wrote:
> > >> Iss this related any way?
>
> > >>http://jolbox.com/forum/viewtopic.php?f=3&t=235
>

[Guillaume Bort]

Have you tried these options?

maxConnectionAge
idleMaxAge
connectionTestStatement

--
Guillaume Bort

[Drew Hamlett]

Yes. I've tried all configurations I can think of. From the ones
that are listed on BoneCP forums to just trial and error. Unless you
have some kind of wild card setting I haven't tried yet.

Take a look at this video.

http://youtu.be/vaaGjK37ayM

The first part the default connection pool in Play 1.x. It counts to
10 resets, counts to 10 resets. There's always a connection in the
pool.

If you look at the second part(around 19seconds) this is the default
connection pool under Play 2.0. It keeps counting up and up. I
haven't seen a setting in BoneCP(in docs or forums) that would change
this. If you leave page idle then when you try to hit the db again
it's either really slow executing a query or it throws Mysql Com link
failure. Something is not right.

If you look through the BoneCP forums people have noticed this too.
The problem is a lot of people on there are doing desktop applications
where it's not as noticeable as a website where you page latency is
really matters(not that it doesn't matter in desktop. It's just more
noticeable).

I feel like people aren't testing this side of Play 2 like I am. The
apps that I've published internally, people have noticed it. If you
leave the page idle and try to hit the database you will see it.

On all my Play 2.0 projects I've switched to C3P0(took the same
settings from Play 1.x) and haven't looked back.

I would strongly recommend looking into this. I wouldn't bring up an
issue like this if I didn't think there was a serious problem or
didn't think it was important. Thanks.

[oblivion]

My application has been up and running without errors at all for
almost ten days now and I have configured NOTHING except the jdbc
connection itself.
There have been idle-times up to 12 hours and nothing, no errors.

db.default.driver=com.mysql.jdbc.Driver
db.default.url="jdbc:mysql://localhost/mydb"
db.default.user=myuser
db.default.pass=mypass

Linux Debian-60-squeeze-64-LAMP 2.6.32-5-amd64
Mysql => 5.1.49-3
Play => latest git

That's it.

[Drew Hamlett]

Is your application public? I think I can demonstrate the hang.

[Guillaume Bort]

Unfortunately I looked into this several times and I never been able
to reproduce the problem.

>  If you leave page idle

For how long?

[oblivion]

No, it's not public.

If you can demonstrate the hang why don't you tell the Play devs and
me how whe can demonstrate it to ourselves?

[oblivion]

Maybe I'll remove Authentication from parts of my app tomorrow, if I
find the time.

[Guillaume Bort]

Looking at your video I don't really see the point. BoneCP doesn't
create new connections every 10 seconds but I don't see how it is a
problem. You said that the interactive timeout for your mysql server
was 8h. So it should be ok to keep a connection opened up to 8h.

Now for me setting:

db.default.maxConnectionAge=10 seconds

Works perfectly. Connections are automatically closed after 10
seconds. Then they are opened again on demand. Settings this value to
something like 4 hours should be ok in your case.

[Drew Hamlett]

Yea the video maybe hard to understand, but C3P0 is not creating new
connections every 10 seconds. It's keeping the same ones open. Where
BoneCP will time them out.

If you go here.

http://atlanticpkg1.herokuapp.com/equipment/case/index

Click first category(also I'm in the process of redesigning so it's a
little bad right now). Then click back. Wait 11 minutes. Just stay
idle. Then click the first category again. You will get an error
because all the connections have timed out of the pool(wait_timeout =
600). This does not happen with C3P0.

Same thing happens on higher wait_timeout or interactive_out(depending
on connection string). Even if the timeout is 4 or 8 hours, if the
connections time out and an error occurs, I don't want this. With
C3P0 it could be idle for a week and never have this occur.

In fact, click this right now. All of the connections are clearing
out of pool right now.

http://atlanticpkg1.herokuapp.com/equipment/case/erector/

It should throw an error.

[Guillaume Bort]

Ok I changed the default configuration. Now it runs a test query every
minute to keep the connection alive.

You can configure it using:

db.default.idleConnectionTestPeriod=5 minutes

(note than using a configuration lower than 1 minute doesn't work and
it's not needed anyway)

[Drew Hamlett]

Hey Guillaume thanks for taking the time to listen to me on this
subject. It's great to talk to the Play developers and give
feedback. I have tried the idleConnectionTestPeriod in the past but
I'll pull latest and try some other things. Personally I would like
to see C3P0 back in. Maybe not by default but as a plugin on release
day. In the time being I will be using the C3P0 plugin I created a
few weeks back to solve this issue. Thanks.

> >> >> On Tue, Jan 31, 2012 at 5:33 PM,DrewHamlett<drewhj...@gmail.com> wrote:
> >> >> > I'm telling you guys the BoneCP plugin is broken at this point.  It's
> >> >> > not correct.  I have several Play 2.0 beta apps in my company already
> >> >> > as well as re-doing our web site.
>
> >> >> > ww is not typo(still in progress)
>
> >> >> > ww.atlanticpkg.com
>
> >> >> > I've made a C3P0 plugin and all the problems go away.  With the BoneCP
> >> >> > the page takes a severe performance hit while getting a
> >> >> > connection(after idle) or even throws a Mysql com link error.  With
> >> >> > C3P0 the connection is just like it was in Play 1.x, which is
> >> >> > perfect.  I have tested this on many mysql databases configured
> >> >> > differently.  It's the same story every time.
>
> >> >> > I hope this can be fixed.
>

[Diego de Moura Duarte]

Hello everyone.

I saw that post, and apparently the "db.default.idleConnectionTestPeriod" param solved the problem.

I would like to reopen the thread, because I'm still having this problem with JDBCConnectionException.

I'm using Play! 2.0.1 with hibernate (version 4.1.4.Final), and I'm using this configuration:

db.default.partitionCount=1

db.default.maxConnectionsPerPartition=60

db.default.minConnectionsPerPartition=30

db.default.acquireIncrement=1

db.default.acquireRetryAttempts=10

db.default.acquireRetryDelay=10 seconds

db.default.connectionTimeout=3 seconds

db.default.idleMaxAge=10 minutes

db.default.idleConnectionTestPeriod=5 minutes

db.default.initSQL="SELECT 1"

db.default.maxConnectionAge=1 hour

I'm receiving that exception:

2012-08-31 10:39:56,609 - [ERROR] - from com.jolbox.bonecp.ConnectionHandle in play-akka.actor.actions-dispatcher-13 

Database access problem. Killing off all remaining connections in the connection pool. SQL State = 08S01

2012-08-31 10:39:56,617 - [WARN] - from org.hibernate.engine.jdbc.spi.SqlExceptionHelper in play-akka.actor.actions-dispatcher-13 
SQL Error: 0, SQLState: 08S01

2012-08-31 10:39:56,617 - [ERROR] - from org.hibernate.engine.jdbc.spi.SqlExceptionHelper in play-akka.actor.actions-dispatcher-13 
Communications link failure

The last packet successfully received from the server was 884,238 milliseconds ago.  The last packet sent successfully to the server was 14 milliseconds ago.

2012-08-31 10:39:56,638 - [ERROR] - from application in play-akka.actor.actions-dispatcher-13 


! @6bgdo12m4 - Internal server error, for request [GET /medias?prj_id=364&start=0&limit=25&cli_id=100203] ->

play.core.ActionInvoker$$anonfun$receive$1$$anon$1: Execution exception [[PersistenceException: org.hibernate.exception.JDBCConnectionException: Communications link failure

The last packet successfully received from the server was 884,238 milliseconds ago.  The last packet sent successfully to the server was 14 milliseconds ago.]]
    at play.core.ActionInvoker$$anonfun$receive$1.apply(Invoker.scala:134) [play.play_2.9.1-2.0.1.jar:2.0.1]
    at play.core.ActionInvoker$$anonfun$receive$1.apply(Invoker.scala:115) [play.play_2.9.1-2.0.1.jar:2.0.1]
    at akka.actor.Actor$class.apply(Actor.scala:311) [com.typesafe.akka.akka-actor-2.0.1.jar:2.0.1]
    at play.core.ActionInvoker.apply(Invoker.scala:113) [play.play_2.9.1-2.0.1.jar:2.0.1]
    at akka.actor.ActorCell.invoke(ActorCell.scala:619) [com.typesafe.akka.akka-actor-2.0.1.jar:2.0.1]
    at akka.dispatch.Mailbox.processMailbox(Mailbox.scala:196) [com.typesafe.akka.akka-actor-2.0.1.jar:2.0.1]
    at akka.dispatch.Mailbox.run(Mailbox.scala:178) [com.typesafe.akka.akka-actor-2.0.1.jar:2.0.1]
    at akka.dispatch.ForkJoinExecutorConfigurator$MailboxExecutionTask.exec(AbstractDispatcher.scala:505) [com.typesafe.akka.akka-actor-2.0.1.jar:2.0.1]
    at akka.jsr166y.ForkJoinTask.doExec(ForkJoinTask.java:259) [com.typesafe.akka.akka-actor-2.0.1.jar:2.0.1]
    at akka.jsr166y.ForkJoinPool$WorkQueue.runTask(ForkJoinPool.java:974) [com.typesafe.akka.akka-actor-2.0.1.jar:2.0.1]
    at akka.jsr166y.ForkJoinPool.runWorker(ForkJoinPool.java:1478) [com.typesafe.akka.akka-actor-2.0.1.jar:2.0.1]
    at akka.jsr166y.ForkJoinWorkerThread.run(ForkJoinWorkerThread.java:104) [com.typesafe.akka.akka-actor-2.0.1.jar:2.0.1]
Caused by: javax.persistence.PersistenceException: org.hibernate.exception.JDBCConnectionException: Communications link failure

The last packet successfully received from the server was 884,238 milliseconds ago.  The last packet sent successfully to the server was 14 milliseconds ago.
    at org.hibernate.ejb.AbstractEntityManagerImpl.convert(AbstractEntityManagerImpl.java:1377) ~[org.hibernate.hibernate-entitymanager-4.1.4.Final.jar:4.1.4.Final]
    at org.hibernate.ejb.AbstractEntityManagerImpl.convert(AbstractEntityManagerImpl.java:1300) ~[org.hibernate.hibernate-entitymanager-4.1.4.Final.jar:4.1.4.Final]
    at org.hibernate.ejb.QueryImpl.getSingleResult(QueryImpl.java:318) ~[org.hibernate.hibernate-entitymanager-4.1.4.Final.jar:4.1.4.Final]
    at org.hibernate.ejb.criteria.CriteriaQueryCompiler$3.getSingleResult(CriteriaQueryCompiler.java:258) ~[org.hibernate.hibernate-entitymanager-4.1.4.Final.jar:4.1.4.Final]
    at models.jpa.JPAHelper.count(JPAHelper.java:95) ~[liquid_2.9.1-1.0-SNAPSHOT.jar:1.0-SNAPSHOT]
    at controllers.Medias.getMedias(Medias.java:55) ~[liquid_2.9.1-1.0-SNAPSHOT.jar:1.0-SNAPSHOT]
    at Routes$$anonfun$routes$1$$anonfun$apply$25$$anonfun$apply$26.apply(routes_routing.scala:200) ~[liquid_2.9.1-1.0-SNAPSHOT.jar:na]
    at Routes$$anonfun$routes$1$$anonfun$apply$25$$anonfun$apply$26.apply(routes_routing.scala:200) ~[liquid_2.9.1-1.0-SNAPSHOT.jar:na]
    at play.core.Router$HandlerInvoker$$anon$4$$anon$1.invocation(Router.scala:1086) ~[play.play_2.9.1-2.0.1.jar:2.0.1]
    at play.core.j.JavaAction$$anon$1.call(JavaAction.scala:33) ~[play.play_2.9.1-2.0.1.jar:2.0.1]
    at play.GlobalSettings$1.call(GlobalSettings.java:57) ~[play.play_2.9.1-2.0.1.jar:2.0.1]
    at mock.MockInterceptor.call(MockInterceptor.java:33) ~[liquid_2.9.1-1.0-SNAPSHOT.jar:1.0-SNAPSHOT]
    at play.db.jpa.TransactionalAction$1.apply(TransactionalAction.java:19) ~[play.play_2.9.1-2.0.1.jar:2.0.1]
    at play.db.jpa.TransactionalAction$1.apply(TransactionalAction.java:17) ~[play.play_2.9.1-2.0.1.jar:2.0.1]
    at play.db.jpa.JPA.withTransaction(JPA.java:104) ~[play.play_2.9.1-2.0.1.jar:2.0.1]
    at play.db.jpa.TransactionalAction.call(TransactionalAction.java:14) ~[play.play_2.9.1-2.0.1.jar:2.0.1]
    at play.core.j.JavaAction$class.apply(JavaAction.scala:74) ~[play.play_2.9.1-2.0.1.jar:2.0.1]
    at play.core.Router$HandlerInvoker$$anon$4$$anon$1.apply(Router.scala:1085) ~[play.play_2.9.1-2.0.1.jar:2.0.1]
    at play.core.ActionInvoker$$anonfun$receive$1$$anonfun$6.apply(Invoker.scala:126) ~[play.play_2.9.1-2.0.1.jar:2.0.1]
    at play.core.ActionInvoker$$anonfun$receive$1$$anonfun$6.apply(Invoker.scala:126) ~[play.play_2.9.1-2.0.1.jar:2.0.1]
    at play.utils.Threads$.withContextClassLoader(Threads.scala:17) ~[play.play_2.9.1-2.0.1.jar:2.0.1]
    at play.core.ActionInvoker$$anonfun$receive$1.apply(Invoker.scala:125) [play.play_2.9.1-2.0.1.jar:2.0.1]
    ... 11 common frames omitted
Caused by: org.hibernate.exception.JDBCConnectionException: Communications link failure

The last packet successfully received from the server was 884,238 milliseconds ago.  The last packet sent successfully to the server was 14 milliseconds ago.
    at org.hibernate.exception.internal.SQLStateConversionDelegate.convert(SQLStateConversionDelegate.java:131) ~[org.hibernate.hibernate-core-4.1.4.Final.jar:4.1.4.Final]
    at org.hibernate.exception.internal.StandardSQLExceptionConverter.convert(StandardSQLExceptionConverter.java:49) ~[org.hibernate.hibernate-core-4.1.4.Final.jar:4.1.4.Final]
    at org.hibernate.engine.jdbc.spi.SqlExceptionHelper.convert(SqlExceptionHelper.java:125) ~[org.hibernate.hibernate-core-4.1.4.Final.jar:4.1.4.Final]
    at org.hibernate.engine.jdbc.spi.SqlExceptionHelper.convert(SqlExceptionHelper.java:110) ~[org.hibernate.hibernate-core-4.1.4.Final.jar:4.1.4.Final]
    at org.hibernate.engine.jdbc.internal.proxy.AbstractStatementProxyHandler.continueInvocation(AbstractStatementProxyHandler.java:129) ~[org.hibernate.hibernate-core-4.1.4.Final.jar:4.1.4.Final]
    at org.hibernate.engine.jdbc.internal.proxy.AbstractProxyHandler.invoke(AbstractProxyHandler.java:81) ~[org.hibernate.hibernate-core-4.1.4.Final.jar:4.1.4.Final]
    at $Proxy37.executeQuery(Unknown Source) ~[na:na]
    at org.hibernate.loader.Loader.getResultSet(Loader.java:1953) ~[org.hibernate.hibernate-core-4.1.4.Final.jar:4.1.4.Final]
    at org.hibernate.loader.Loader.doQuery(Loader.java:829) ~[org.hibernate.hibernate-core-4.1.4.Final.jar:4.1.4.Final]
    at org.hibernate.loader.Loader.doQueryAndInitializeNonLazyCollections(Loader.java:289) ~[org.hibernate.hibernate-core-4.1.4.Final.jar:4.1.4.Final]
    at org.hibernate.loader.Loader.doList(Loader.java:2438) ~[org.hibernate.hibernate-core-4.1.4.Final.jar:4.1.4.Final]
    at org.hibernate.loader.Loader.doList(Loader.java:2424) ~[org.hibernate.hibernate-core-4.1.4.Final.jar:4.1.4.Final]
    at org.hibernate.loader.Loader.listIgnoreQueryCache(Loader.java:2254) ~[org.hibernate.hibernate-core-4.1.4.Final.jar:4.1.4.Final]
    at org.hibernate.loader.Loader.list(Loader.java:2249) ~[org.hibernate.hibernate-core-4.1.4.Final.jar:4.1.4.Final]
    at org.hibernate.loader.hql.QueryLoader.list(QueryLoader.java:470) ~[org.hibernate.hibernate-core-4.1.4.Final.jar:4.1.4.Final]
    at org.hibernate.hql.internal.ast.QueryTranslatorImpl.list(QueryTranslatorImpl.java:355) ~[org.hibernate.hibernate-core-4.1.4.Final.jar:4.1.4.Final]
    at org.hibernate.engine.query.spi.HQLQueryPlan.performList(HQLQueryPlan.java:195) ~[org.hibernate.hibernate-core-4.1.4.Final.jar:4.1.4.Final]
    at org.hibernate.internal.SessionImpl.list(SessionImpl.java:1248) ~[org.hibernate.hibernate-core-4.1.4.Final.jar:4.1.4.Final]
    at org.hibernate.internal.QueryImpl.list(QueryImpl.java:101) ~[org.hibernate.hibernate-core-4.1.4.Final.jar:4.1.4.Final]
    at org.hibernate.ejb.QueryImpl.getSingleResult(QueryImpl.java:285) ~[org.hibernate.hibernate-entitymanager-4.1.4.Final.jar:4.1.4.Final]
    ... 30 common frames omitted

Caused by: com.mysql.jdbc.exceptions.jdbc4.CommunicationsException: Communications link failure

The last packet successfully received from the server was 884,238 milliseconds ago.  The last packet sent successfully to the server was 14 milliseconds ago.
    at sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native Method) ~[na:1.6.0_31]
    at sun.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:39) ~[na:1.6.0_31]
    at sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:27) ~[na:1.6.0_31]
    at java.lang.reflect.Constructor.newInstance(Constructor.java:513) ~[na:1.6.0_31]
    at com.mysql.jdbc.Util.handleNewInstance(Util.java:411) ~[mysql.mysql-connector-java-5.1.18.jar:na]
    at com.mysql.jdbc.SQLError.createCommunicationsException(SQLError.java:1116) ~[mysql.mysql-connector-java-5.1.18.jar:na]
    at com.mysql.jdbc.MysqlIO.reuseAndReadPacket(MysqlIO.java:3102) ~[mysql.mysql-connector-java-5.1.18.jar:na]
    at com.mysql.jdbc.MysqlIO.reuseAndReadPacket(MysqlIO.java:2991) ~[mysql.mysql-connector-java-5.1.18.jar:na]
    at com.mysql.jdbc.MysqlIO.checkErrorPacket(MysqlIO.java:3532) ~[mysql.mysql-connector-java-5.1.18.jar:na]
    at com.mysql.jdbc.MysqlIO.sendCommand(MysqlIO.java:2002) ~[mysql.mysql-connector-java-5.1.18.jar:na]
    at com.mysql.jdbc.MysqlIO.sqlQueryDirect(MysqlIO.java:2163) ~[mysql.mysql-connector-java-5.1.18.jar:na]
    at com.mysql.jdbc.ConnectionImpl.execSQL(ConnectionImpl.java:2624) ~[mysql.mysql-connector-java-5.1.18.jar:na]
    at com.mysql.jdbc.PreparedStatement.executeInternal(PreparedStatement.java:2127) ~[mysql.mysql-connector-java-5.1.18.jar:na]
    at com.mysql.jdbc.PreparedStatement.executeQuery(PreparedStatement.java:2293) ~[mysql.mysql-connector-java-5.1.18.jar:na]
    at com.jolbox.bonecp.PreparedStatementHandle.executeQuery(PreparedStatementHandle.java:172) ~[com.jolbox.bonecp-0.7.1.RELEASE.jar:0.7.1.RELEASE]
    at sun.reflect.GeneratedMethodAccessor26.invoke(Unknown Source) ~[na:na]
    at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) ~[na:1.6.0_31]
    at java.lang.reflect.Method.invoke(Method.java:597) ~[na:1.6.0_31]
    at org.hibernate.engine.jdbc.internal.proxy.AbstractStatementProxyHandler.continueInvocation(AbstractStatementProxyHandler.java:122) ~[org.hibernate.hibernate-core-4.1.4.Final.jar:4.1.4.Final]
    ... 45 common frames omitted

Caused by: java.io.EOFException: Can not read response from server. Expected to read 4 bytes, read 0 bytes before connection was unexpectedly lost.

    at com.mysql.jdbc.MysqlIO.readFully(MysqlIO.java:2552) ~[mysql.mysql-connector-java-5.1.18.jar:na]
    at com.mysql.jdbc.MysqlIO.reuseAndReadPacket(MysqlIO.java:3002) ~[mysql.mysql-connector-java-5.1.18.jar:na]
    ... 57 common frames omitted

[Marc Siegel]

Bump -- we've also seen this error. What is going on?