Problem when increasing maxJobsPerAcquisition

As we transition to the new Hyland Community, some post links may be temporarily disrupted as we finalize redirects. We apologize for the inconvenience and are working to resolve this as quickly as possible. Details.

hugues

I am evaluating usage of Activiti in our project.  I made a simple test Java app that embeds Activiti and creates process instances. The process definition includes a timer event, and I am testing how the JobExecutor deals with many jobs that have a same due date. I created 1000 instances, and they all have a user task with a timer boundary event with the exact same due date and time.
When maxJobsPerAcquisition is 1, everything goes very well: JobExecutor executes the jobs as fast as it can using its threads pool.
When I set maxJobsPerAcquisition to 3, some jobs fails into error, randomly.  The higher the maxJobsPerAcquisition, the more frequent I see jobs in error.
Note that I do have only one Activiti instance runnning (my test main app). I know that when multiple Activiti access the same DB, maxJobsPerAcuqisition should stay 1 because of locking problems. I was wondering if the problem here is due to locking or not.

The stack trace of one such job error is (I removed some lines to keep it shorter):

Exception in thread "pool-1-thread-8" org.activiti.engine.ActivitiException: Job 2575 failed
   at org.activiti.engine.impl.cmd.ExecuteJobsCmd.execute(ExecuteJobsCmd.java:83)
   at org.activiti.engine.impl.interceptor.CommandInvoker.execute(CommandInvoker.java:24)
   (…)
   at java.lang.Thread.run(Thread.java:722)
Caused by: org.apache.ibatis.exceptions.PersistenceException: 
### Error querying database.  Cause: java.sql.SQLException: Error accessing PooledConnection. Connection is invalid.
### The error may exist in org/activiti/db/mapping/entity/HistoricActivityInstance.xml
### The error may involve org.activiti.engine.impl.persistence.entity.HistoricActivityInstanceEntity.selectHistoricActivityInstancesByQueryCriteria
### The error occurred while executing a query
### SQL: select * from ( select a.*, ROWNUM rnum from (     select RES.*            from ACT_HI_ACTINST RES      WHERE  RES.EXECUTION_ID_ = ?                              and RES.ACT_ID_ = ?                                            and RES.END_TIME_ is null           order by RES.ID_ asc        ) a where ROWNUM < ?) where rnum  >= ?
### Cause: java.sql.SQLException: Error accessing PooledConnection. Connection is invalid.
   at org.apache.ibatis.exceptions.ExceptionFactory.wrapException(ExceptionFactory.java:23)
   at org.apache.ibatis.session.defaults.DefaultSqlSession.selectList(DefaultSqlSession.java:107)
   at org.apache.ibatis.session.defaults.DefaultSqlSession.selectList(DefaultSqlSession.java:98)
   at org.activiti.engine.impl.db.DbSqlSession.selectListWithRawParameter(DbSqlSession.java:286)
   at org.activiti.engine.impl.db.DbSqlSession.selectList(DbSqlSession.java:277)
   at org.activiti.engine.impl.db.DbSqlSession.selectList(DbSqlSession.java:267)
   at org.activiti.engine.impl.persistence.entity.HistoricActivityInstanceEntityManager.findHistoricActivityInstancesByQueryCriteria(HistoricActivityInstanceEntityManager.java:56)
   (…)
Caused by: java.sql.SQLException: Error accessing PooledConnection. Connection is invalid.
   at org.apache.ibatis.datasource.pooled.PooledConnection.checkConnection(PooledConnection.java:254)
   at org.apache.ibatis.datasource.pooled.PooledConnection.invoke(PooledConnection.java:243)
   (…)
‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍

I use an Oracle DB for persistence. I have default connection pool set-up.

Is this problem linked to db locking and maxJobsPerAcquisition value, or is it "simply" a connection pool issue ? Would the connection pool be too small when we increase the maxJobsPerAcquisition, and therefore the number of parallel job executions ?
Any hint will be welcome to help me searching the right direction.

Thanks a lot!

jbarrez

The exception seems to point to a connection pool problem.

Note that the default connection pool is like 10 connections.
Try changing it to a real connection pool (c3p0, boneCP, etc.).