Upgrade from 1.5.5 to 2.0.0 was unsuccessful in clustered environment: Cause: java.sql.SQLException: Lock wait timeout exceeded; Any ideas?

[Adrien Lamoureux <la...@gmail.com>]

Hi there,

First, I would like to say thank you for a great product. We have been using
it since mid 2009 in a production environment (for authoring), and
publishing content from the repository to static files for reading.

But today, deploying to the latest version of Jacrkabbit: 2.0.0 from 1.5.5
caused our entire server cluster to fail. It appears that the update has
caused database locking issues. We are using deployment model 1 where a
local repository is run in each instance of tomcat (we have 3 of them) with
clustering/journal enabled.

We are using java 1.5.0_16 with Tomcat 5.5.23 and Mysql 5.1.39 in linux
based environments.

This error never showed up during testing on our test server or on our local
development systems, and the only difference is that we have more then one
repository in the cluster on production. I would show a stack trace, but
strangely, the lock timeouts are occurring only with non-jcr tables during
routine actions in other areas of our site, even though they have nothing to
do with Jackrabbit.

Here is a fragment of the persistence manager we are using for workspaces
and versioning:

        <PersistenceManager
class="org.apache.jackrabbit.core.persistence.pool.MySqlPersistenceManager">
          <param name="url"
value="jdbc:mysql://[DBHOSTNAME]:3306/jcrrepos?characterEncoding=UTF-8&amp;autoReconnect=true"/>
          <param name="driver" value="com.mysql.jdbc.Driver"/>
  <param name="user" value="[DBUSERNAME]"/>
  <param name="password" value="[DBPASSWORD]"/>
                  <param name="schemaObjectPrefix" value="${wsp.name}_"/>
  <param name="externalBLOBs" value="false"/>
        </PersistenceManager>

and here is the cluster element we are using:
<Cluster id="${hostname}-${rep.home}" syncDelay="2000"> <Journal
class="org.apache.jackrabbit.core.journal.DatabaseJournal"> <param
name="driver" value="com.mysql.jdbc.Driver" /> <param name="url"
value="jdbc:mysql://[DBHOSTNAME]:3306/jcrrepos?characterEncoding=UTF-8&amp;autoReconnect=true"
/> <param name="user" value="[DBUSERNAME]"/> <param name="password"
value="[DBPASSWORD]"/> <param name="schemaObjectPrefix" value="cluster_"/>
</Journal> </Cluster>

We have one other repository instance in the cluster running in standalone
mode with syncDelay="500" for publishing changes in the repository.

We are still trying to diagnose the problem, but all we know so far is that
disabling jackrabbit solved the problem. We will revert to 1.5.5 this
evening, but we were looking forward to using connection pooling, so any
ideas as to what might be causing this?

Thanks.

Adrien

Re: Upgrade from 1.5.5 to 2.0.0 was unsuccessful in clustered environment: Cause: java.sql.SQLException: Lock wait timeout exceeded; Any ideas?

[Thomas Müller <th...@day.com>]

Hi,


> Could you point me in the right direction for a production-ready model 3
> deployment model (where we can access the repository remotely)?

There is some documentation available here:
http://wiki.apache.org/jackrabbit/RemoteAccess

Regards,
Thomas

Re: Upgrade from 1.5.5 to 2.0.0 was unsuccessful in clustered environment: Cause: java.sql.SQLException: Lock wait timeout exceeded; Any ideas?

[Adrien Lamoureux <la...@gmail.com>]

Ok, I shall from now on, though I will at least update you on the situation.

We are bundling jackrabbit with our application, and one of the jars in
question after the upgrade (commons dbcp 1.2.1 1.2.2) was causing problems
with database replication, which only happens in our production environment.

Could you point me in the right direction for a production-ready model 3
deployment model (where we can access the repository remotely)?

I'm concerned that bundling jackrabbit using either model 1 or model 2 will
cause dependency issues in non-related code, and would like to have the
repository independent from our code.

Thanks

Adrien

On Sun, Feb 7, 2010 at 11:53 PM, Thomas Müller <th...@day.com>wrote:

> Hi,
>
> Please use the 'user' list for questions.
>
> > the lock timeouts are occurring only with non-jcr tables during routine
> actions in other areas of our site, even though they have nothing to do with
> Jackrabbit.
>
> It sounds like the problem is not related to Jackrabbit then.
>
> > disabling jackrabbit solved the problem
>
> It could be due to lower database activity. What happens if you use
> two independent databases?
>
> Regards,
> Thomas
>

Re: Upgrade from 1.5.5 to 2.0.0 was unsuccessful in clustered environment: Cause: java.sql.SQLException: Lock wait timeout exceeded; Any ideas?

[Thomas Müller <th...@day.com>]

Hi,

Please use the 'user' list for questions.

> the lock timeouts are occurring only with non-jcr tables during routine actions in other areas of our site, even though they have nothing to do with Jackrabbit.

It sounds like the problem is not related to Jackrabbit then.

> disabling jackrabbit solved the problem

It could be due to lower database activity. What happens if you use
two independent databases?

Regards,
Thomas