Troubleshooting: Difference between revisions

From Obsidian Scheduler
Jump to navigationJump to search
Created page with "The following are steps to troubleshooting common problems users have had in Obsidian. == My job isn't running when expected. Why not?== This may be a case where your schedule i..."
 
No edit summary
Line 21: Line 21:
</pre>
</pre>


If you encounter an error like the one above and are using MySQL (particularly version 5.0), there is a good chance you are hitting a relatively common [http://bugs.mysql.com/bug.php?id=20932|MySQL problem]. We do recommend users upgrade to MySQL 5.5 where possible, and even to use another supported platform, but we know this isn't a useful option to many users, so we have found ways around this problem. This problem seems to occur mainly on new Obsidian instances, so once corrected, there is a good chance you will never see the issue again.
If you encounter an error like the one above and are using MySQL (particularly version 5.0), there is a good chance you are hitting a relatively common [http://bugs.mysql.com/bug.php?id=20932 MySQL problem]. We do recommend users upgrade to MySQL 5.5 where possible, and even to use another supported platform, but we know this isn't a useful option to many users, so we have found ways around this problem. This problem seems to occur mainly on new Obsidian instances, so once corrected, there is a good chance you will never see the issue again.


Two approaches have been used with success:
Two approaches have been used with success:
# In MySQL's my.cnf file, temporarily change (or add) the following line, and then restart mysqld: <pre>innodb_lock_wait_timeout = 600</pre><br />This appears to only be an issue when Obsidian first gets running, and it can typically be reverted after a while.<br /><br />
# In MySQL's my.cnf file, temporarily change (or add) the following line, and then restart mysqld: <pre>innodb_lock_wait_timeout = 600</pre><br />This appears to only be an issue when Obsidian first gets running, and it can typically be reverted after a while.<br /><br />
# At a MySQL prompt, run the following command: <pre>optimize table semaphore;</pre><br /> If this resolves your issue, we suggest optimizing all your tables using [http://dev.mysql.com/doc/refman/5.0/en/mysqlcheck.html|mysqlcheck].
# At a MySQL prompt, run the following command: <pre>optimize table semaphore;</pre><br /> If this resolves your issue, we suggest optimizing all your tables using [http://dev.mysql.com/doc/refman/5.0/en/mysqlcheck.html mysqlcheck].

Revision as of 21:25, 29 September 2012

The following are steps to troubleshooting common problems users have had in Obsidian.

My job isn't running when expected. Why not?

This may be a case where your schedule isn't correct for the execution times you want, or the job may be failing.

  1. First, you should confirm that your job isn't actually running. You can check for the Job History screen to see if there are any scheduled or completed jobs. You may see that a job failed; to see details on it, simply expand the row to see an exception stack trace and the option to resubmit the job. If your job is failing, you may wish to set up notifications so that you know of future problems quickly.
  2. If you don't see any jobs listed there, you can confirm what execution times your schedule will result in. To see what times your job will execute, check the Run Time Preview screen.
  3. Next, you can check for any general server health issues. To do so, first you can search the Logs screen for any errors or warnings that may indicate a server issue.
  4. Finally, check your application logs (e.g. Tomcat stdout logs, etc.). If there are database issues, these logs may be the only place where server issues are logged.
  5. If all else fails, contact us.

I'm getting a "Lock wait timeout exception". What's going on?

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)

If you encounter an error like the one above and are using MySQL (particularly version 5.0), there is a good chance you are hitting a relatively common MySQL problem. We do recommend users upgrade to MySQL 5.5 where possible, and even to use another supported platform, but we know this isn't a useful option to many users, so we have found ways around this problem. This problem seems to occur mainly on new Obsidian instances, so once corrected, there is a good chance you will never see the issue again.

Two approaches have been used with success:

  1. In MySQL's my.cnf file, temporarily change (or add) the following line, and then restart mysqld:
    innodb_lock_wait_timeout = 600

    This appears to only be an issue when Obsidian first gets running, and it can typically be reverted after a while.

  2. At a MySQL prompt, run the following command:
    optimize table semaphore;

    If this resolves your issue, we suggest optimizing all your tables using mysqlcheck.