I've seen the same issue periodically.
Basically, it seems to have something to do with the connection pool
never being emptied, so you wind up with a closed connection.
And yes, I've tried autoReconnect=true,and several related variants.
I finally switched to using DBCP, which lets you specify a "test"
query to ensure that the connection is still valid, as well as a host
of other options.
I haven't seen the exception since. One downside to switching is that
at least the 2.x modeler chokes on trying to load the project when
using the DBCP connection factory.
Something about the auto-adapter detection failing.
Cheers,
Robert
On Mar 26, 2008, at 3/264:51 AM , Alexander Lamb (dev) wrote:
> Yes, we did add this parameter but we still can reproduce the bug
> locally (on the desktop using Jetty).
>
> But it does it only on one application which has something
> "special": it has two models that we merge when starting the app.
>
> On another app also in version 3 but with only one model, it works.
>
> To test, we simply kill MySql while the app is running, then restart
> MySql. The reconnect works with the app with one model and fails
> partially with the app with the merged models. Once the exception
> has been raised, the app continues fine (and so finally reconnects
> correctly). There is just no way of knowing where the exception will
> be raised (we tried catching an exception at one place but then the
> exception appeared at some other place).
>
> Alex
>
> Le 26 mars 08 à 10:27, Andrus Adamchik a écrit :
>> Are you using "autoReconnect=true" parameter in the MySQL
>> connection URL?
>>
>> Thanks,
>> Andrus
>>
>>
>> On Mar 26, 2008, at 10:44 AM, Alexander Lamb wrote:
>>
>>> Hello List,
>>>
>>> We have an application, deployed successfully with Tapestry 5.0.11
>>> and Cayenne 3.0M3 on Tomcat 6 with MySQL 5.0.
>>>
>>> Everything is fine until the point where a long period of
>>> inactivity has passed and (we suppose) all the DataContexts are
>>> garbage collected (we create one DataContext per user session).
>>> The first user who logs in will generate an error on (again, what
>>> we suppose) is a problem reconnecting to MySQL.
>>>
>>> To avoid the problem, we "ping" the app to keep it alive... We
>>> also tried to catch the Exception but doing so simply pushes the
>>> problem to another part of the program. The funny thing is that it
>>> is not the first attempt to connect to the database but maybe the
>>> first attempt using either a stored query in the model or raw SQL.
>>>
>>> Here is the kind of message we get:
>>>
>>> Communications link failure due to underlying exception:
>>>
>>> ** BEGIN NESTED EXCEPTION **
>>>
>>> java.io.EOFException
>>>
>>> STACKTRACE:
>>>
>>> java.io.EOFException
>>> at com.mysql.jdbc.MysqlIO.readFully(MysqlIO.java:1905)
>>> at com.mysql.jdbc.MysqlIO.reuseAndReadPacket(MysqlIO.java:2351)
>>> at com.mysql.jdbc.MysqlIO.checkErrorPacket(MysqlIO.java:2862)
>>> at com.mysql.jdbc.MysqlIO.sendCommand(MysqlIO.java:1571)
>>> at com.mysql.jdbc.MysqlIO.sqlQueryDirect(MysqlIO.java:1666)
>>> at com.mysql.jdbc.Connection.execSQL(Connection.java:2988)
>>> at com.mysql.jdbc.Connection.setAutoCommit(Connection.java:4913)
>>> at
>>> org
>>> .apache
>>> .cayenne
>>> .conn.PooledConnectionImpl.getConnection(PooledConnectionImpl.java:
>>> 129)
>>> at
>>> org
>>> .apache
>>> .cayenne.conn.PoolManager.uncheckConnection(PoolManager.java:383)
>>> at
>>> org.apache.cayenne.conn.PoolManager.getConnection(PoolManager.java:
>>> 367)
>>> at
>>> org.apache.cayenne.conn.PoolManager.getConnection(PoolManager.java:
>>> 344)
>>> at org.apache.cayenne.access.DataNode
>>> $TransactionDataSource.getConnection(DataNode.java:321)
>>> at
>>> org.apache.cayenne.access.DataNode.performQueries(DataNode.java:209)
>>> at
>>> org
>>> .apache
>>> .cayenne
>>> .access.DataDomainQueryAction.runQuery(DataDomainQueryAction.java:
>>> 442)
>>> at org.apache.cayenne.access.DataDomainQueryAction.access
>>> $000(DataDomainQueryAction.java:67)
>>> at org.apache.cayenne.access.DataDomainQueryAction
>>> $2.transform(DataDomainQueryAction.java:415)
>>> at
>>> org
>>> .apache.cayenne.access.DataDomain.runInTransaction(DataDomain.java:
>>> 847)
>>> at
>>> org
>>> .apache
>>> .cayenne
>>> .access
>>> .DataDomainQueryAction
>>> .runQueryInTransaction(DataDomainQueryAction.java:412)
>>> at
>>> org
>>> .apache
>>> .cayenne
>>> .access.DataDomainQueryAction.execute(DataDomainQueryAction.java:
>>> 119)
>>> at org.apache.cayenne.access.DataDomain.onQuery(DataDomain.java:
>>> 740)
>>> at
>>> org
>>> .apache
>>> .cayenne
>>> .util
>>> .ObjectContextQueryAction.runQuery(ObjectContextQueryAction.java:
>>> 296)
>>> at org.apache.cayenne.util.ObjectContextQueryAction
>>> $1.createObject(ObjectContextQueryAction.java:286)
>>> at org.apache.cayenne.cache.MapQueryCache.get(MapQueryCache.java:
>>> 74)
>>> at
>>> org
>>> .apache
>>> .cayenne
>>> .util
>>> .ObjectContextQueryAction
>>> .interceptLocalCache(ObjectContextQueryAction.java:258)
>>> at
>>> org
>>> .apache
>>> .cayenne
>>> .util
>>> .ObjectContextQueryAction.execute(ObjectContextQueryAction.java:82)
>>> at org.apache.cayenne.access.DataContext.onQuery(DataContext.java:
>>> 1331)
>>> at
>>> org
>>> .apache.cayenne.access.DataContext.performQuery(DataContext.java:
>>> 1320)
>>> at
>>> ch
>>> .rodano
>>> .studies
>>> .services
>>> .StudySession
>>> .getRunningTotalPatientsByMonthForRegistryCenters
>>> (StudySession.java:466)
>>>
>>>
>>> etc...
>>>
>>> Thanks for any idea!
>>>
>>> Alex
>>>
>>> --
>>> Alexander Lamb
>>> Founding Associate
>>> RODANOTECH Sàrl
>>>
>>> 4 ch. de la Tour de Champel
>>> 1206 Geneva
>>> Switzerland
>>>
>>> Tel: 022 347 77 37
>>> Fax: 022 347 77 38
>>>
>>> http://www.rodanotech.ch
>>>
>>>
>>>
>>>
>>
>
This archive was generated by hypermail 2.0.0 : Wed Mar 26 2008 - 09:01:10 EDT