Hide Forgot
Date of First Response: 2009-08-18 09:04:34 project_key: SOA See attached example. It uses a recommended way how to handle unrepsponsive services. If the service is running too long there is a timer that signals the process to continue. In CP01 it completes the rest of the process. In CP02 it generates an exception that it cannot continue as the process variables are not present. The unresponsive service is Service5 and process is redirected to another service. I was not able to reproduce the issue when 1) Timeout was not inside fork 2) The timeout transition was the same as the regular one 2009-08-18 10:44:41,549 ERROR [org.jbpm.graph.def.GraphElement] action threw exception: unable to resolve property: theBody org.mvel.CompileException: unable to resolve property: theBody at org.mvel.optimizers.impl.refl.ReflectiveAccessorOptimizer.compileGetChain(ReflectiveAccessorOptimizer.java:289) at org.mvel.optimizers.impl.refl.ReflectiveAccessorOptimizer.optimizeAccessor(ReflectiveAccessorOptimizer.java:110) at org.mvel.optimizers.impl.refl.ReflectiveAccessorOptimizer.get(ReflectiveAccessorOptimizer.java:94) at org.mvel.MVEL.getProperty(MVEL.java:572) at org.jboss.soa.esb.services.jbpm.JBpmObjectMapper.setOnEsbMessage(JBpmObjectMapper.java:140) at org.jboss.soa.esb.services.jbpm.JBpmObjectMapper.mapFromJBpmToEsbMessage(JBpmObjectMapper.java:81) at org.jboss.soa.esb.services.jbpm.actionhandlers.EsbActionHandler.execute(EsbActionHandler.java:103) at org.jbpm.graph.def.Action.execute(Action.java:137) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) at java.lang.reflect.Method.invoke(Method.java:597) at org.hibernate.proxy.pojo.javassist.JavassistLazyInitializer.invoke(JavassistLazyInitializer.java:173) at org.jbpm.graph.def.Action_$$_javassist_34.execute(Action_$$_javassist_34.java) at org.jbpm.graph.def.GraphElement.executeAction(GraphElement.java:284) at org.jbpm.graph.def.Node.execute(Node.java:395) at org.jbpm.graph.def.Node.enter(Node.java:375) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) at java.lang.reflect.Method.invoke(Method.java:597) at org.hibernate.proxy.pojo.javassist.JavassistLazyInitializer.invoke(JavassistLazyInitializer.java:173) at org.jbpm.graph.def.Node_$$_javassist_81.enter(Node_$$_javassist_81.java) at org.jbpm.graph.def.Transition.take(Transition.java:167) at org.jbpm.graph.def.Node.leave(Node.java:453) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) at java.lang.reflect.Method.invoke(Method.java:597) at org.hibernate.proxy.pojo.javassist.JavassistLazyInitializer.invoke(JavassistLazyInitializer.java:173) at org.jbpm.graph.def.Node_$$_javassist_81.leave(Node_$$_javassist_81.java) at org.jbpm.graph.exe.Token.signal(Token.java:221) at org.jbpm.graph.exe.Token.signal(Token.java:177) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) at java.lang.reflect.Method.invoke(Method.java:597) at org.hibernate.proxy.pojo.javassist.JavassistLazyInitializer.invoke(JavassistLazyInitializer.java:173) at org.jbpm.graph.exe.Token_$$_javassist_14.signal(Token_$$_javassist_14.java) at org.jbpm.job.Timer.execute(Timer.java:89) at org.jbpm.job.executor.JobExecutorThread.executeJob(JobExecutorThread.java:172) at org.jbpm.job.executor.JobExecutorThread.run(JobExecutorThread.java:63) Caused by: org.mvel.PropertyAccessException: unable to resolve property: theBody at org.mvel.optimizers.impl.refl.ReflectiveAccessorOptimizer.getBeanProperty(ReflectiveAccessorOptimizer.java:383) at org.mvel.optimizers.impl.refl.ReflectiveAccessorOptimizer.compileGetChain(ReflectiveAccessorOptimizer.java:258) ... 41 more
Link: Added: This issue depends JBPM-2489
Attachment: Added: Quickstart_bpm_orchestration2.esb
In what node did this error occur?
It is node with action EsbActionHandler - the standard action delivered with ESB to invoke ESB service and is represented as ESB node in GUI designer
Sorry, yes I saw that node the timer is on from the processdefinition. Was just wondering if the error also occured within that specific node or in e.g. a next node. What do you btw mean with the 'regular' one? Is that a jbpm default transition or the one named 'ok'? Can you check what happens if you switch the transitions in the definition?
I don't see evidence that the problem is in jBPM code. Both the stack trace and the process definition to the ESB action code. Is the standard DB-based scheduler service in use here? It would not fire a timer before the previous transaction commits, saves the variable value and the timer record. The job executor code has barely changed. I could only understand this deviation in behavior if an alternate, non-transactional scheduler service was employed. I will be experimenting with the JBPM2094Test to see if I can reproduce.
If I take SOA 4.3.0 CP01 and replace the existing 3.2.5SP5 version of jBPM with the 3.2.7CR1 version from CP02 CR2, I can reproduce this error.
I've put together a test case for this issue (JBPM2489Test). Token.equals() is broken, causing variables to be created in the wrong place**. This could be why the process loses access to process variables. Providing adequate equals and hash code functions results in the expected behavior. ** For future reference: New variables "dallas" and "theBody" were created at the LA token level. The expected behavior is to overwrite the existing variables at the root token level.
Resolved upstream as of version 3.2.7.
Please review the following draft text added to the Resolved Issues section of the Release Notes: https://jira.jboss.org/jira/browse/JBPM-2489 A regression was introduced in release 4.3.CP02 that generated an org.mvel.CompileException exception. This occurred when a service was running too long, at which point a timer would signal the process to continue. Instead of doing so, the failure occurred, as the process lost access to variables. This regression was a result of the Token.equals() code being broken, causing the process variables to be created in the wrong places. To rectify this issue, the EqualsUtil.equals code has been deprecated. All uses of it have been replaced by corrected equals() and hashCode() implementations. As a result, access to process variables is no longer lost and the process is completed in the expected manner.
Verified in ER1