topic RuntimeService.deleteProcessInstance cause StackOverflowErr in Alfresco Archive

RuntimeService.deleteProcessInstance cause StackOverflowErr

razu — Tue, 04 Oct 2011 14:43:45 GMT

I use Activity 5.7 and encounter a StackOverflowError after call RuntimeService.deleteProcessInstance on running process with about 4500 instances of UserTask.I can observe about 10 minutes of querying database, and after that StackOverflowError is thrown.Any hints how to manage this?This is fragmen

Re: RuntimeService.deleteProcessInstance cause StackOverflowErr

ronald_van_kuij — Tue, 04 Oct 2011 15:58:52 GMT

4500 instances of a usertask? Wow… sounds like a bad design. What is it that your process must do?

Re: RuntimeService.deleteProcessInstance cause StackOverflowErr

razu — Wed, 05 Oct 2011 06:38:27 GMT

Well, bad design or not, I have such a need. I would say it may take 20 minutes to use RuntimeService.deleteProcessInstance, but it should finally do it's job, not throw StackOverflowError. I use JAVA_OPTS = "-Xms256m -Xmx1790m -XX:MaxPermSize=512m", that is a lot of memory.

Is there any chance to optimize this?

Re: RuntimeService.deleteProcessInstance cause StackOverflowErr

frederikherema1 — Wed, 05 Oct 2011 06:41:05 GMT

How is your history set? You know a lot of entities are created when having 4500 user-tasks, and we can't cascade delete them all. So there will be n times 4500 deletes going on, we can't do magic either you know… You can always look for suggestions on how we can optimize the deletes (however, a lot of thinking and work was perofrmed to get to the way it's going happening right now).

Re: RuntimeService.deleteProcessInstance cause StackOverflowErr

razu — Wed, 05 Oct 2011 07:46:58 GMT

My history level is now set to "full", I need access to process variables after it's termination. I'm looking for other place for storing such informations, then I'll be able to set history level to "activity", will it help?. I'll report my results then.

Re: RuntimeService.deleteProcessInstance cause StackOverflowErr

frederikherema1 — Wed, 05 Oct 2011 10:05:55 GMT

Razu,

The amount of history gathered with "full" is much more than with "activity". So the deletes in a system with level set to full will be much heavier (ie. more seperate queries) -> so it will help.

Re: RuntimeService.deleteProcessInstance cause StackOverflowErr

razu — Wed, 05 Oct 2011 14:23:18 GMT

I set history level to "activity" and I can observe better ACTIVITI efficiency, after call RuntimeService.deleteProcessInstance I noticed that database table ACT_HI_DETAIL is not queried like before, but after 10 minutes of waiting the result was the same as with "full" history level.

Is there any recursion during deleting process instance?
What is reasonable limit of task instances in a running process?

I can check one more possibility - set history level to "none", does it make sense yet?


java.lang.StackOverflowError: null
 at java.lang.Exception.<init>(Exception.java:41) ~[na:1.5.0_22]
 at java.io.IOException.<init>(IOException.java:40) ~[na:1.5.0_22]
 at java.io.StringReader.ensureOpen(StringReader.java:39) ~[na:1.5.0_22]
 at java.io.StringReader.read(StringReader.java:73) ~[na:1.5.0_22]
 at org.apache.ibatis.ognl.JavaCharStream.FillBuff(JavaCharStream.java:127) ~[mybatis-3.0.4.jar:3.0.4]
 at org.apache.ibatis.ognl.JavaCharStream.ReadByte(JavaCharStream.java:149) ~[mybatis-3.0.4.jar:3.0.4]
 at org.apache.ibatis.ognl.JavaCharStream.readChar(JavaCharStream.java:234) ~[mybatis-3.0.4.jar:3.0.4]
 at org.apache.ibatis.ognl.JavaCharStream.BeginToken(JavaCharStream.java:168) ~[mybatis-3.0.4.jar:3.0.4]
 at org.apache.ibatis.ognl.OgnlParserTokenManager.getNextToken(OgnlParserTokenManager.java:1471) ~[mybatis-3.0.4.jar:3.0.4]
 at org.apache.ibatis.ognl.OgnlParser.jj_scan_token(OgnlParser.java:3419) ~[mybatis-3.0.4.jar:3.0.4]
 at org.apache.ibatis.ognl.OgnlParser.jj_3R_21(OgnlParser.java:3232) ~[mybatis-3.0.4.jar:3.0.4]
 at org.apache.ibatis.ognl.OgnlParser.jj_3_3(OgnlParser.java:3226) ~[mybatis-3.0.4.jar:3.0.4]
 at org.apache.ibatis.ognl.OgnlParser.jj_2_3(OgnlParser.java:2676) ~[mybatis-3.0.4.jar:3.0.4]
 at org.apache.ibatis.ognl.OgnlParser.primaryExpression(OgnlParser.java:1711) ~[mybatis-3.0.4.jar:3.0.4]
 at org.apache.ibatis.ognl.OgnlParser.navigationChain(OgnlParser.java:1409) ~[mybatis-3.0.4.jar:3.0.4]
 at org.apache.ibatis.ognl.OgnlParser.unaryExpression(OgnlParser.java:1361) ~[mybatis-3.0.4.jar:3.0.4]
 at org.apache.ibatis.ognl.OgnlParser.multiplicativeExpression(OgnlParser.java:1100) ~[mybatis-3.0.4.jar:3.0.4]
 at org.apache.ibatis.ognl.OgnlParser.additiveExpression(OgnlParser.java:1011) ~[mybatis-3.0.4.jar:3.0.4]
 at org.apache.ibatis.ognl.OgnlParser.shiftExpression(OgnlParser.java:849) ~[mybatis-3.0.4.jar:3.0.4]
 at org.apache.ibatis.ognl.OgnlParser.relationalExpression(OgnlParser.java:571) ~[mybatis-3.0.4.jar:3.0.4]
 at org.apache.ibatis.ognl.OgnlParser.equalityExpression(OgnlParser.java:456) ~[mybatis-3.0.4.jar:3.0.4]
 at org.apache.ibatis.ognl.OgnlParser.andExpression(OgnlParser.java:397) ~[mybatis-3.0.4.jar:3.0.4]
 at org.apache.ibatis.ognl.OgnlParser.exclusiveOrExpression(OgnlParser.java:338) ~[mybatis-3.0.4.jar:3.0.4]
 at org.apache.ibatis.ognl.OgnlParser.inclusiveOrExpression(OgnlParser.java:279) ~[mybatis-3.0.4.jar:3.0.4]
 at org.apache.ibatis.ognl.OgnlParser.logicalAndExpression(OgnlParser.java:220) ~[mybatis-3.0.4.jar:3.0.4]
 at org.apache.ibatis.ognl.OgnlParser.logicalOrExpression(OgnlParser.java:161) ~[mybatis-3.0.4.jar:3.0.4]
 at org.apache.ibatis.ognl.OgnlParser.conditionalTestExpression(OgnlParser.java:116) ~[mybatis-3.0.4.jar:3.0.4]
 at org.apache.ibatis.ognl.OgnlParser.assignmentExpression(OgnlParser.java:73) ~[mybatis-3.0.4.jar:3.0.4]
 at org.apache.ibatis.ognl.OgnlParser.expression(OgnlParser.java:26) ~[mybatis-3.0.4.jar:3.0.4]
 at org.apache.ibatis.ognl.OgnlParser.topLevelExpression(OgnlParser.java:16) ~[mybatis-3.0.4.jar:3.0.4]
 at org.apache.ibatis.ognl.Ognl.parseExpression(Ognl.java:111) ~[mybatis-3.0.4.jar:3.0.4]
 at org.apache.ibatis.ognl.Ognl.getValue(Ognl.java:435) ~[mybatis-3.0.4.jar:3.0.4]
 at org.apache.ibatis.ognl.Ognl.getValue(Ognl.java:414) ~[mybatis-3.0.4.jar:3.0.4]
 at org.apache.ibatis.builder.xml.dynamic.ExpressionEvaluator.evaluateIterable(ExpressionEvaluator.java:28) ~[mybatis-3.0.4.jar:3.0.4]
 at org.apache.ibatis.builder.xml.dynamic.ForEachSqlNode.apply(ForEachSqlNode.java:36) ~[mybatis-3.0.4.jar:3.0.4]
 at org.apache.ibatis.builder.xml.dynamic.MixedSqlNode.apply(MixedSqlNode.java:14) ~[mybatis-3.0.4.jar:3.0.4]
 at org.apache.ibatis.builder.xml.dynamic.TrimSqlNode.apply(TrimSqlNode.java:27) ~[mybatis-3.0.4.jar:3.0.4]
 at org.apache.ibatis.builder.xml.dynamic.MixedSqlNode.apply(MixedSqlNode.java:14) ~[mybatis-3.0.4.jar:3.0.4]
 at org.apache.ibatis.builder.xml.dynamic.MixedSqlNode.apply(MixedSqlNode.java:14) ~[mybatis-3.0.4.jar:3.0.4]
 at org.apache.ibatis.builder.xml.dynamic.DynamicSqlSource.getBoundSql(DynamicSqlSource.java:22) ~[mybatis-3.0.4.jar:3.0.4]
 at org.apache.ibatis.mapping.MappedStatement.getBoundSql(MappedStatement.java:198) ~[mybatis-3.0.4.jar:3.0.4]
 at org.apache.ibatis.executor.BaseExecutor.createCacheKey(BaseExecutor.java:115) ~[mybatis-3.0.4.jar:3.0.4]
 at org.apache.ibatis.executor.BaseExecutor.query(BaseExecutor.java:90) ~[mybatis-3.0.4.jar:3.0.4]
 at org.apache.ibatis.executor.CachingExecutor.query(CachingExecutor.java:72) ~[mybatis-3.0.4.jar:3.0.4]
 at org.apache.ibatis.session.defaults.DefaultSqlSession.selectList(DefaultSqlSession.java:75) ~[mybatis-3.0.4.jar:3.0.4]
 at org.apache.ibatis.session.defaults.DefaultSqlSession.selectList(DefaultSqlSession.java:69) ~[mybatis-3.0.4.jar:3.0.4]
 at org.activiti.engine.impl.db.DbSqlSession.selectList(DbSqlSession.java:193) ~[activiti-engine-5.7.jar:5.7]
 at org.activiti.engine.impl.persistence.entity.TaskManager.findTasksByQueryCriteria(TaskManager.java:89) ~[activiti-engine-5.7.jar:5.7]
 at org.activiti.engine.impl.TaskQueryImpl.executeList(TaskQueryImpl.java:334) ~[activiti-engine-5.7.jar:5.7]
 at org.activiti.engine.impl.AbstractQuery.list(AbstractQuery.java:114) ~[activiti-engine-5.7.jar:5.7]
 at org.activiti.engine.impl.persistence.entity.ExecutionEntity.remove(ExecutionEntity.java:764) ~[activiti-engine-5.7.jar:5.7]
 at org.activiti.engine.impl.pvm.runtime.AtomicOperationDeleteCascadeFireActivityEnd.eventNotificationsCompleted(AtomicOperationDeleteCascadeFireActivityEnd.java:61) ~[activiti-engine-5.7.jar:5.7]
 at org.activiti.engine.impl.pvm.runtime.AbstractEventAtomicOperation.execute(AbstractEventAtomicOperation.java:52) ~[activiti-engine-5.7.jar:5.7]
 at org.activiti.engine.impl.interceptor.CommandContext.performOperation(CommandContext.java:76) ~[activiti-engine-5.7.jar:5.7]
 at org.activiti.engine.impl.persistence.entity.ExecutionEntity.performOperation(ExecutionEntity.java:481) ~[activiti-engine-5.7.jar:5.7]
 at org.activiti.engine.impl.pvm.runtime.AbstractEventAtomicOperation.execute(AbstractEventAtomicOperation.java:45) ~[activiti-engine-5.7.jar:5.7]
 at org.activiti.engine.impl.interceptor.CommandContext.performOperation(CommandContext.java:76) ~[activiti-engine-5.7.jar:5.7]
 at org.activiti.engine.impl.persistence.entity.ExecutionEntity.performOperation(ExecutionEntity.java:481) ~[activiti-engine-5.7.jar:5.7]
 at org.activiti.engine.impl.pvm.runtime.AtomicOperationDeleteCascade.execute(AtomicOperationDeleteCascade.java:31) ~[activiti-engine-5.7.jar:5.7]
 at org.activiti.engine.impl.interceptor.CommandContext.performOperation(CommandContext.java:76) ~[activiti-engine-5.7.jar:5.7]
 at org.activiti.engine.impl.persistence.entity.ExecutionEntity.performOperation(ExecutionEntity.java:481) ~[activiti-engine-5.7.jar:5.7]
 at org.activiti.engine.impl.pvm.runtime.AtomicOperationDeleteCascadeFireActivityEnd.eventNotificationsCompleted(AtomicOperationDeleteCascadeFireActivityEnd.java:66) ~[activiti-engine-5.7.jar:5.7]

…

Re: RuntimeService.deleteProcessInstance cause StackOverflowErr

ronald_van_kuij — Wed, 05 Oct 2011 15:31:57 GMT

I can check one more possibility - set history level to "none", does it make sense yet?

Setting to none? Then you have no 'history'. What do you mean by "Does it make sense yet?"

To just have access to the process variables at the end, you can use a process end listener. Search the forum for that.

Re: RuntimeService.deleteProcessInstance cause StackOverflowErr

razu — Thu, 06 Oct 2011 11:23:43 GMT

I created simple process that contains one multi instance UserTask, this UserTask generates 4500 instances without any additional variables. I run this process with history level set to "none", and I invoked RuntimeService.deleteProcessInstance on it.

Result: java.lang.StackOverflowError

The number 4500 is not taken from a sky, I need this number of tasks in my process, but I was curious which number of tasks generates StackOverflowError during delete process innstance, and it looks like 1000 tasks is acceptable, but 1100 tasks already causes an error. I've tested this on JDK 1.5.0_22 , ACTIVITI 5.7 and JAVA_OPTS set to "-Xms256m -Xmx1790m -XX:MaxPermSize=512m".

Do you have any ideas how to workaround this problem? Should I report a bug?

Re: RuntimeService.deleteProcessInstance cause StackOverflowErr

behemot1 — Fri, 07 Oct 2011 10:07:36 GMT

Dear Activiti Core Developers!

Could you be so kind and try to investigate the problem which Razu has reported ?
It's very important to have a bpm engine without such limititations to produce actually good quality software.

Regards,
Wojciech Pieprzyca

Re: RuntimeService.deleteProcessInstance cause StackOverflowErr

ronald_van_kuij — Fri, 07 Oct 2011 13:07:27 GMT

As Frederik mentioned, a lot of investigation already took place.

How is your history set? You know a lot of entities are created when having 4500 user-tasks, and we can't cascade delete them all. So there will be n times 4500 deletes going on, we can't do magic either you know… You can always look for suggestions on how we can optimize the deletes (however, a lot of thinking and work was perofrmed to get to the way it's going happening right now).

Short term solution: You can always create queries in jdbc yourself, delete things in several batches with explicit commits etc… It will stil take long then, use less memory, but with the risk of having an inconsistent db for processes where it fails half way. So you'd have to do it intelligently.

Re: RuntimeService.deleteProcessInstance cause StackOverflowErr

frederikherema1 — Mon, 10 Oct 2011 08:19:25 GMT

We are aware of the stackoverflow and are looking into a solution to fix this.

Re: RuntimeService.deleteProcessInstance cause StackOverflowErr

ronald_van_kuij — Fri, 16 Dec 2011 15:11:18 GMT

Did you try increasing the stack size? e.g. by adding the flag -Xss1024k in the VM Arguments or in mb by using -Xss1m for example or bigger

Re: RuntimeService.deleteProcessInstance cause StackOverflowErr

razu — Mon, 09 Jan 2012 11:53:37 GMT

I've been increasing stack size continuously, and finally after setting -Xss8m I was able to delete process instance, it took about 20 min. My process contains one multi-instance UserTask and 4500 instances of it.
Thank you for your help.

Re: RuntimeService.deleteProcessInstance cause StackOverflowErr

ronald_van_kuij — Mon, 09 Jan 2012 16:41:01 GMT

My process contains one multi-instance UserTask and 4500 instances of it.

What kind of process is this if I may ask?

Re: RuntimeService.deleteProcessInstance cause StackOverflowErr

razu — Tue, 10 Jan 2012 11:48:57 GMT

The process represent business client campaign. It contains of selection step. Selection should select list of business clients and add them some attributes. Each business client can be selected by many users, user who is responsible for business client select it and set him some attributes.
When all business clients have been selected, process ends generating some summary data.

The selection step is realized as multi-instance UserTask, each instance of this task represents one business client. Person responsible for specific business client takes this instance (via claim in API), add some attributes to it and close it (via complete in API). List of business clients that is processed have size = 4500, so 4500 instances of multi-instance UserTask is generated from that list.