2009-05-19 20 views
7

Tengo una aplicación que ejecuta Quartz 1.6.1 w/persistent job store, con MySQL 5.1 como DB. Esta aplicación solía iniciarse bien en Tomcat6. En algún momento, se comenzó a lanzar la siguiente excepción en cada arranque:Solución de problemas coherente "SQLException: tiempo de espera de espera de bloqueo excedido"

- MisfireHandler: Error handling misfires: Failure obtaining db row lock: Lock wait timeout exceeded; try restarting transaction 
org.quartz.impl.jdbcjobstore.LockException: Failure obtaining db row lock: Lock wait timeout exceeded; try restarting transaction [See nested exception: java.sql.SQLException: Lock wait timeout exceeded; try restarting transaction] 
    at org.quartz.impl.jdbcjobstore.StdRowLockSemaphore.executeSQL(StdRowLockSemaphore.java:112) 
    at org.quartz.impl.jdbcjobstore.DBSemaphore.obtainLock(DBSemaphore.java:112) 
    at org.quartz.impl.jdbcjobstore.JobStoreSupport.doRecoverMisfires(JobStoreSupport.java:3075) 
    at org.quartz.impl.jdbcjobstore.JobStoreSupport$MisfireHandler.manage(JobStoreSupport.java:3838) 
    at org.quartz.impl.jdbcjobstore.JobStoreSupport$MisfireHandler.run(JobStoreSupport.java:3858) 
Caused by: java.sql.SQLException: Lock wait timeout exceeded; try restarting transaction 
    at com.mysql.jdbc.SQLError.createSQLException(SQLError.java:1055) 
    at com.mysql.jdbc.SQLError.createSQLException(SQLError.java:956) 
    at com.mysql.jdbc.MysqlIO.checkErrorPacket(MysqlIO.java:3491) 
    at com.mysql.jdbc.MysqlIO.checkErrorPacket(MysqlIO.java:3423) 
    at com.mysql.jdbc.MysqlIO.sendCommand(MysqlIO.java:1936) 
    at com.mysql.jdbc.MysqlIO.sqlQueryDirect(MysqlIO.java:2060) 
    at com.mysql.jdbc.ConnectionImpl.execSQL(ConnectionImpl.java:2542) 
    at com.mysql.jdbc.PreparedStatement.executeInternal(PreparedStatement.java:1734) 
    at com.mysql.jdbc.PreparedStatement.executeQuery(PreparedStatement.java:1885) 
    at com.mchange.v2.c3p0.impl.NewProxyPreparedStatement.executeQuery(NewProxyPreparedStatement.java:76) 
    at org.quartz.impl.jdbcjobstore.StdRowLockSemaphore.executeSQL(StdRowLockSemaphore.java:92) 
    ... 4 more 

Debo mencionar esta aplicación también utiliza JPA w/Hibernate utilizando C3P0 para la agrupación de conexiones de origen de datos. Esta excepción siempre se produce directamente después de que JPA termina de actualizar mi esquema.

Primero, me actualicé a Quartz 1.6.5 y la excepción desapareció, pero la aplicación parece estar congelada. La última cosa en los registros - donde la excepción solía ser - es:

...hbm2ddl stuff... 
2969 [Thread-1] INFO org.hibernate.tool.hbm2ddl.SchemaUpdate - schema update complete 
- Handling 6 trigger(s) that missed their scheduled fire-time. 

Sin nada viene después, y la aplicación de web no atender las solicitudes; simplemente cuelgan indefinidamente.

Cuando corro MySQL cliente de línea de comandos con DEMOSTRACIÓN DE ESTADO INNODB justo después de la excepción, demuestra consistentemente dos operaciones sospechosas:

---------- 
SEMAPHORES 
---------- 
OS WAIT ARRAY INFO: reservation count 49, signal count 49 
Mutex spin waits 0, rounds 2100, OS waits 0 
RW-shared spins 115, OS waits 49; RW-excl spins 0, OS waits 0 
------------ 
TRANSACTIONS 
------------ 
Trx id counter 0 165688 
Purge done for trx's n:o < 0 165685 undo n:o < 0 0 
History list length 12 
LIST OF TRANSACTIONS FOR EACH SESSION: 
---TRANSACTION 0 0, not started, OS thread id 5012 
MySQL thread id 8, query id 1798 localhost 127.0.0.1 root 
SHOW INNODB STATUS 
---TRANSACTION 0 165687, ACTIVE 300 sec, OS thread id 3772 
2 lock struct(s), heap size 320, 1 row lock(s) 
MySQL thread id 30, query id 1795 localhost 127.0.0.1 my_app 
---TRANSACTION 0 165685, ACTIVE 360 sec, OS thread id 5460 
2 lock struct(s), heap size 320, 1 row lock(s), undo log entries 1 
MySQL thread id 34, query id 1680 localhost 127.0.0.1 my_app 

estoy en busca de orientación sobre la forma de promover investigar este problema ¿Tal vez si pudiera identificar de alguna manera a los propietarios de estas dos transacciones, o qué recursos están bloqueando?

Actualización: He eliminado todas las filas de los qrtz_simple_triggers mesa sin problema. Luego traté de hacer lo mismo en la tabla qrtz_triggers y mi cliente MySQL arrojó un error de "bloqueo de tiempo de espera excedido". En este punto, detuve mi aplicación (aún colgada) y pude eliminar todas las filas de la tabla qrtz_triggers. Una vez hecho esto, pude arrancar con éxito mi aplicación.

Parece que necesito registrar un nuevo error de Quartz, pero me gustaría poder darles más información sobre lo que realmente está pasando aquí. Entonces, según la pregunta original, ¿cómo puedo solucionar este tipo de problemas?

Respuesta

1

Ha intentado ejecutar
show processlist
o
show full processlist
desde la línea de comandos de MySQL? Esto normalmente le mostrará el sql completo de la consulta que se está bloqueando. También le mostrará cuánto tiempo el proceso ha estado ejecutando esa consulta. Puede ayudarlo a acercarse a la respuesta.

Cuestiones relacionadas