Troubleshooting

Timeout errors

If you see these kinds of errors, the problem is that the workflow engine is taking longer than expected to respond:

You can increase this timeout by modifying the OpenKM rest.client.call.timeout configuration property. By default, it is set to 15 seconds, but you can increase it to 30 or 60 seconds.

Too many follow-up requests error

If you see errors like this on the OpenKM side:

Please, verify the user and password configured in these configuration properties:

• workflow.adapter.login
• workflow.adapter.password

And also take a look at openkm.log and jbpm-console.log files to get more information.

The request was rejected because the URL was not normalized

The most common cause is a slash at the end of the workflow.adapter.url OpenKM configuration property. To fix, remove the final slash.

It should be something like "http://localhost:8080/jbpm-console" and not "http://localhost:8080/jbpm-console/".

An instance cannot be ended and suspended at the same time

This should never happend, but in certain circunstances some task can be in this illegal stated. To detect which process instance is this one, we need to execute this sentence:

select * from JBPM_PROCESSINSTANCE pi WHERE pi.ISSUSPENDED_ = 1 and pi.END_ is not null;

Once we got the process instance id, we can change the suspended flag:

update JBPM_PROCESSINSTANCE pi set pi.ISSUSPENDED_ = 0 where pi.ID_ = 540;

And now the problem is solved. 

Database connection issues

If you have problem with the database connection it's interesting to debug the database connection pool. This can be done adding these properties to the jbpm-console.properties file:

hibernate.c3p0.debugUnreturnedConnectionStackTraces=true
hibernate.c3p0.unreturnedConnectionTimeout=10
hibernate.c3p0.minPoolSize=10
hibernate.c3p0.maxPoolSize=50
logging.level.com.mchange.v2=INFO

According to C3P0 documentation, unreturnedConnectionTimeout defines a limit (in seconds) to how long a connection may remain checked out. If set to a nozero value, unreturned, checked-out connections that exceed this limit will be summarily destroyed, and then replaced in the pool. Obviously, you must take care to set this parameter to a value large enough that all intended operations on checked out connections have time to complete. You can use this parameter to merely workaround unreliable client apps that fail to close() connections.

Much better than working-around is fixing. If, in addition to setting unreturnedConnectionTimeout, you set debugUnreturnedConnectionStackTraces to true, then a stack trace will be captured each time a connection is checked-out. Whenever an unreturned connection times out, that stack trace will be printed, revealing where a connection was checked out that was not checked in promptly. debugUnreturnedConnectionStackTraces is intended to be used only for debugging, as capturing a stack trace can slow down connection check-out."