Troubleshooting

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 or use our Free Live Chat Support link on the left.

When I try to enter my job's class name in the UI, I get the message "Could not locate the class [MyJob]". What's the problem?

This problem is generally caused by one of these issues:

1. The JAR file containing the job is not on the classpath of the servlet container (Tomcat/Jetty/etc). JARs are placed under WEB-INF/lib in the web application.
2. Obsidian has not been restarted after updating the classpath with a new JAR.
3. Job does not implement com.carfey.ops.job.SchedulableJob.
4. User has entered the job class with leading or trailing whitespace, or the job class has been misspelled.
5. User did not enter the fully qualified class name (e.g. MyJob instead of com.company.MyJob).

Just a note, you can use the Classpath Scanning feature to automatically find your jobs so you wont' need to type them in as they'll be added to the list of available jobs.

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 chance you are hitting a MySQL bug. 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.

I'm trying to start Obsidian using the Quick Start method, but I'm seeing "java.net.BindException".

java.net.BindException: Permission denied
at java.net.PlainSocketImpl.socketBind(Native Method)
at java.net.PlainSocketImpl.bind(PlainSocketImpl.java:383)
at java.net.ServerSocket.bind(ServerSocket.java:328)
at java.net.ServerSocket.<init>(ServerSocket.java:194)

This is a common error on *nix platforms, including OS X. On these platforms, ports 0-1023 are privileged. By default, only the root user will be able to bind to them. Obsidian's quick start default configuration uses port 80, which can cause the above error.

In addition, you may see similar issues if a port is already in use, in which case changing the port as described below will also fix the issue.

To resolve this, you have two options:

1. Use the "sudo" command to elevate your privileges to bind on port 80.
2. Change the port you use.
   1. If using the Ant script, change the deployPort setting:

      ant run.war -DdeployPort=8080 -Dspawn=true

   2. If using the command line to start Winstone, edit winstone.properties by setting the httpPort property to the desired value (e.g. 8080).