[JBoss JIRA] Created: (JBPM-1145) Loops realized via a decision node will eventually cause a StackOverflow Exception
by R??diger Schmitz (JIRA)
Loops realized via a decision node will eventually cause a StackOverflow Exception
----------------------------------------------------------------------------------
Key: JBPM-1145
URL: http://jira.jboss.com/jira/browse/JBPM-1145
Project: JBoss jBPM
Issue Type: Bug
Components: Core Engine
Affects Versions: jBPM 3.1.4, jBPM 3.1
Reporter: R??diger Schmitz
Assigned To: Tom Baeyens
Executing a simple, iterative loop implemented with a decision node will cause a StackOverflowException (see below for stacktrace). Apparently the iterative calls are executing using recursive calls. This approach fails if a medium sized loop should be executed (a simple reproducing testcase only reached 161 loop iterations before failing). I see this implementation style as highly problematic when processing medium-sized quantities of input data...
java.lang.StackOverflowError
at java.lang.ClassLoader.findBootstrapClass(Native Method)
at java.lang.ClassLoader.findBootstrapClass0(ClassLoader.java:891)
at java.lang.ClassLoader.loadClass(ClassLoader.java:301)
at java.lang.ClassLoader.loadClass(ClassLoader.java:299)
at sun.misc.Launcher$AppClassLoader.loadClass(Launcher.java:268)
at java.lang.ClassLoader.loadClass(ClassLoader.java:251)
at java.lang.ClassLoader.loadClassInternal(ClassLoader.java:319)
at org.hibernate.loader.Loader.loadCollection(Loader.java:1926)
at org.hibernate.loader.collection.CollectionLoader.initialize(CollectionLoader.java:71)
at org.hibernate.persister.collection.AbstractCollectionPersister.initialize(AbstractCollectionPersister.java:520)
at org.hibernate.event.def.DefaultInitializeCollectionEventListener.onInitializeCollection(DefaultInitializeCollectionEventListener.java:60)
at org.hibernate.impl.SessionImpl.initializeCollection(SessionImpl.java:1627)
at org.hibernate.collection.AbstractPersistentCollection.initialize(AbstractPersistentCollection.java:344)
at org.hibernate.collection.AbstractPersistentCollection.read(AbstractPersistentCollection.java:86)
at org.hibernate.collection.PersistentList.iterator(PersistentList.java:115)
at org.jbpm.graph.def.GraphElement.findExceptionHandler(GraphElement.java:358)
at org.jbpm.graph.def.GraphElement.raiseException(GraphElement.java:326)
at org.jbpm.graph.def.GraphElement.raiseException(GraphElement.java:343)
at org.jbpm.graph.def.Node.execute(Node.java:332)
at org.jbpm.graph.def.Node.enter(Node.java:316)
at org.jbpm.graph.def.Node$$FastClassByCGLIB$$d187eeda.invoke(<generated>)
at net.sf.cglib.proxy.MethodProxy.invoke(MethodProxy.java:149)
at org.hibernate.proxy.CGLIBLazyInitializer.intercept(CGLIBLazyInitializer.java:161)
<snip>...a ton of repeating stacktraceelements omitted... <snap>
at org.hibernate.proxy.CGLIBLazyInitializer.intercept(CGLIBLazyInitializer.java:161)
at org.jbpm.graph.def.Node$$EnhancerByCGLIB$$cb94b78_3.enter(<generated>)
at org.jbpm.graph.def.Transition.take(Transition.java:119)
at org.jbpm.graph.def.Node.leave(Node.java:382)
at org.jbpm.graph.exe.ExecutionContext.leaveNode(ExecutionContext.java:136)
at org.jbpm.graph.node.Decision.execute(Decision.java:145)
at org.jbpm.graph.def.Node.enter(Node.java:316)
at org.jbpm.graph.def.Node$$FastClassByCGLIB$$d187eeda.invoke(<generated>)
at net.sf.cglib.proxy.MethodProxy.invoke(MethodProxy.java:149)
at org.hibernate.proxy.CGLIBLazyInitializer.intercept(CGLIBLazyInitializer.java:161)
at org.jbpm.graph.def.Node$$EnhancerByCGLIB$$cb94b78_3.enter(<generated>)
at org.jbpm.graph.def.Transition.take(Transition.java:119)
at org.jbpm.graph.def.Node.leave(Node.java:382)
at org.jbpm.graph.def.Node.leave(Node.java:346)
at org.jbpm.graph.exe.ExecutionContext.leaveNode(ExecutionContext.java:120)
at com.atos.worldline.kams.workflow.pf.BusinessObjectAccessHandler.doExecute(BusinessObjectAccessHandler.java:114)
at com.atos.worldline.kams.workflow.pf.AbstractBusinessMethodHandler.execute(AbstractBusinessMethodHandler.java:60)
at org.jbpm.graph.def.Action.execute(Action.java:123)
at org.jbpm.graph.def.Action$$FastClassByCGLIB$$7876e90e.invoke(<generated>)
at net.sf.cglib.proxy.MethodProxy.invoke(MethodProxy.java:149)
at org.hibernate.proxy.CGLIBLazyInitializer.intercept(CGLIBLazyInitializer.java:161)
at org.jbpm.graph.def.Action$$EnhancerByCGLIB$$889386ac_3.execute(<generated>)
at org.jbpm.graph.def.Node.execute(Node.java:328)
at org.jbpm.graph.def.Node.enter(Node.java:316)
at org.jbpm.graph.def.Node$$FastClassByCGLIB$$d187eeda.invoke(<generated>)
at net.sf.cglib.proxy.MethodProxy.invoke(MethodProxy.java:149)
at org.hibernate.proxy.CGLIBLazyInitializer.intercept(CGLIBLazyInitializer.java:161)
at org.jbpm.graph.def.Node$$EnhancerByCGLIB$$cb94b78_3.enter(<generated>)
at org.jbpm.graph.def.Transition.take(Transition.java:119)
at org.jbpm.graph.def.Node.leave(Node.java:382)
at org.jbpm.graph.exe.ExecutionContext.leaveNode(ExecutionContext.java:136)
at org.jbpm.graph.node.Decision.execute(Decision.java:145)
at org.jbpm.graph.def.Node.enter(Node.java:316)
at org.jbpm.graph.def.Node$$FastClassByCGLIB$$d187eeda.invoke(<generated>)
at net.sf.cglib.proxy.MethodProxy.invoke(MethodProxy.java:149)
at org.hibernate.proxy.CGLIBLazyInitializer.intercept(CGLIBLazyInitializer.java:161)
at org.jbpm.graph.def.Node$$EnhancerByCGLIB$$cb94b78_3.enter(<generated>)
at org.jbpm.graph.def.Transition.take(Transition.java:119)
at org.jbpm.graph.def.Node.leave(Node.java:382)
at org.jbpm.graph.def.Node.leave(Node.java:346)
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
16 years, 5 months
[JBoss JIRA] Created: (JBPM-1201) Resurrect MemLeakTest
by Thomas Diesler (JIRA)
Resurrect MemLeakTest
---------------------
Key: JBPM-1201
URL: http://jira.jboss.com/jira/browse/JBPM-1201
Project: JBoss jBPM
Issue Type: Task
Security Level: Public (Everyone can see)
Reporter: Thomas Diesler
[15:54:19] Thomas Diesler: there seems to be a circular dependency in modules identity and jpdl/jar
[15:54:42] ... how should it be?
[15:54:52] Tom Baeyens: good question
[15:55:20] ... jpdl jar should not need identity
[15:55:38] ... but for building the suite, the identity is needed
[15:55:40] Thomas Diesler: yes, I found that
[15:55:54] Tom Baeyens: building the suite should be in dist
[15:56:01] Thomas Diesler: yes, I found that too
[15:56:24] ... I am swithcing the build to maven
[15:56:32] Tom Baeyens: where did you find the circular dep ?
[15:56:52] Thomas Diesler: can't the identity tests live in module identity?
[15:57:19] Tom Baeyens: are there identity tests in jpdl/jar ?
[15:57:30] Thomas Diesler: yes
[15:57:48] Tom Baeyens: probably there is some reason i can't remember now
[15:57:59] ... i'll see if i can quickly re-find it
[15:58:19] Thomas Diesler: ok, but identity depends on jpdl-core, right?
[15:58:32] ... don't worry
[15:58:40] ... I'll sort it out
[15:59:30] Tom Baeyens: MemLeakTest ?
[15:59:50] Thomas Diesler: yes
[16:00:17] Tom Baeyens: just delete the test
[16:00:19] ... :-)
[16:00:46] ... it's a kind of integration test
[16:01:00] ... which i guess is not part of the continuous integration
[16:01:05] Thomas Diesler: with all the other props and stuff?
[16:01:24] Tom Baeyens: other props ?
[16:01:46] Thomas Diesler: next to the test are lots of config files
[16:01:52] Tom Baeyens: right
[16:02:01] Thomas Diesler: delete them too?
[16:02:04] Tom Baeyens: maybe it makes sense to put the perf package into a separate module
[16:02:28] ... you can delete all of it
[16:02:41] ... but in case we ever want to do performance tests
[16:02:51] ... then those could provide a good start
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
16 years, 6 months