[jboss-user] [JBoss jBPM] - Re: Stale state problem kills process instance?
Hi Ed, Thanks for your reply. Maybe I misunderstood you, but I do not set the attribute async to anything at all. According to the specification, this attribute default value is "false". In my opinion this is a strange attribute to have for a Fork Node, but again according to the specification every Node has it. So, without setting the async attribute and by using a Fork Node, I get a parallel split and the activities following the Fork Node are enabled (and possible to execute) in parallel. Nothing strange here. Sorry, if I comments have caused confusion. The problem mentioned initially was that the engine sometimes generates an error message when Fork is used (and breaks down, i.e., a restart is needed). I observed that it only happens if one of the outgoing transitions from a Fork misses a name (which is the default setting). Note, that this is just an observation based on a problem I faced and a couple of examples I was running. I have not made any real "trouble shooting" of the problem. I just though my observation can help others. Regards, Petia View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4171131#4171131 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4171131 ___ jboss-user mailing list jboss-user@lists.jboss.org https://lists.jboss.org/mailman/listinfo/jboss-user
[jboss-user] [JBoss jBPM] - Re: Stale state problem kills process instance?
Petia, If you have async=false on everything, all the work is performed sequentially on one thread - there's no opportunity for a stale object (or race condition) to occur. -Ed View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4171123#4171123 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4171123 ___ jboss-user mailing list jboss-user@lists.jboss.org https://lists.jboss.org/mailman/listinfo/jboss-user
[jboss-user] [JBoss jBPM] - Re: Stale state problem kills process instance?
Hi Ed, Below is the example which works nicely for me. Note that, the fork and join have the default setting async="false". The transitions "to B1" and "to B2" going out from the Fork node, do not have any conditions specified. The only difference of this example, from a non-working example is that both transitions going out from the Fork node have names, i.e. "to B1" and "to B2" below. I hope this helps, Petia | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4171118#4171118 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4171118 ___ jboss-user mailing list jboss-user@lists.jboss.org https://lists.jboss.org/mailman/listinfo/jboss-user
[jboss-user] [JBoss jBPM] - Re: Stale state problem kills process instance?
You probably have a race condition between the beginning of the async node finishing up, and the end of the async firing. I wasn't clear on what's causing the wait node to complete - can it be very quick? If so, try putting a delay in there and see if it goes away. This isn't a fix, obviously - it just will point a finger at the problem. -Ed View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4171102#4171102 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4171102 ___ jboss-user mailing list jboss-user@lists.jboss.org https://lists.jboss.org/mailman/listinfo/jboss-user
[jboss-user] [JBoss jBPM] - Re: Stale state problem kills process instance?
Hi, I am running jBPM 3.2.3 out-of-the-box (with Java 1.6). I got the same problem as described above. Coincidentally, I discovered that if both transitions outgoing from the Fork have the attribute "name" set the problem does not appear (the default setting is that the first transition does not have this attribute set to anything). Kind regards, Petia View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4171093#4171093 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4171093 ___ jboss-user mailing list jboss-user@lists.jboss.org https://lists.jboss.org/mailman/listinfo/jboss-user
[jboss-user] [JBoss jBPM] - Re: Stale state problem kills process instance?
I'm having the same problem. Apparantly having wait states or not in the child paths (tokens) makes a difference. If in the child paths the process must wait (until it is signalled again) then I see in the database 3 tokens: root, child 1 and child 2. If the complete process, including the child paths, runs to completion with one signal() then I see in the database only 2 tokens: root and a child. I'm wondering if the 2nd child token is not reusing the record of the 1st token in some way? View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4140908#4140908 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4140908 ___ jboss-user mailing list jboss-user@lists.jboss.org https://lists.jboss.org/mailman/listinfo/jboss-user
[jboss-user] [JBoss jBPM] - Re: Stale state problem kills process instance?
I have the similar problem with hibernate323, jbpm321, jboss420.
anonymous wrote : 2007-07-30 23:14:20,714 5742606 ERROR
[com.rrd.pmt.workflow.service.Task] (pool-6-thread-1:)
| org.hibernate.StaleObjectStateException: Row was updated or deleted by
another transaction (or unsaved-value mapping was incorrect):
[org.jbpm.graph.exe.Token#11804]
| at
org.hibernate.persister.entity.AbstractEntityPersister.forceVersionIncrement(AbstractEntityPersister.java:1235)
| at
org.hibernate.event.def.AbstractLockUpgradeEventListener.upgradeLock(AbstractLockUpgradeEventListener.java:82)
| at
org.hibernate.event.def.DefaultLockEventListener.onLock(DefaultLockEventListener.java:64)
| at org.hibernate.impl.SessionImpl.fireLock(SessionImpl.java:584)
| at org.hibernate.impl.SessionImpl.lock(SessionImpl.java:576)
| at org.jbpm.graph.node.Join.execute(Join.java:109)
| at org.jbpm.graph.def.Node.enter(Node.java:318)
| 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:585)
| at
org.hibernate.proxy.pojo.javassist.JavassistLazyInitializer.invoke(JavassistLazyInitializer.java:173)
| at
org.jbpm.graph.def.Node_$$_javassist_544.enter(Node_$$_javassist_544.java)
| at org.jbpm.graph.def.Transition.take(Transition.java:151)
| at org.jbpm.graph.def.Node.leave(Node.java:393)
| 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:585)
| at
org.hibernate.proxy.pojo.javassist.JavassistLazyInitializer.invoke(JavassistLazyInitializer.java:173)
| at
org.jbpm.graph.def.Node_$$_javassist_544.leave(Node_$$_javassist_544.java)
| at org.jbpm.graph.exe.Token.signal(Token.java:194)
| at org.jbpm.graph.exe.Token.signal(Token.java:139)
| at
com.rrd.pmt.workflow.service.AbstractTaskExecutorService.doTranstion(AbstractTaskExecutorService.java:123)
| at com.rrd.pmt.workflow.service.Task.run(Task.java:40)
| at
java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:417)
| at
java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:269)
| at java.util.concurrent.FutureTask.run(FutureTask.java:123)
| at
java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:650)
| at
java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:675)
| at java.lang.Thread.run(Thread.java:613)
|
The strange thing is if I use ejb timers to execute all the fork steps,
everything is fine. However, if driving one of the fork steps with external
jbpmconfigure, although still using the same hibernate session factory as other
timers steps, it will have this error, my external jbpmconfig code looks like:
caller:
|
| public void doTranstion(long id, String tokenPath, String path) throws
Exception {
| JbpmContext jbpmContext =
JbpmUtil.getJbpmConfig().createJbpmContext();
| try {
| ProcessInstance processInstance =
jbpmContext.loadProcessInstanceForUpdate(id);
| if (processInstance == null) {
| logger.debug("ProcessInstance " + id + " does
not exist anymore. Ignore it");
| return;
| }
|
| Token token = processInstance.findToken(tokenPath);
| logger.info("ProcessIntance " + processInstance.getId()
+ " changing from node[" +
token.getNode().getDefaultLeavingTransition().getFrom().getName() + "] to
node["
| +
token.getNode().getDefaultLeavingTransition().getTo().getName() + "]" + ".
File=" + path);
| token.signal();
| } catch (Exception e) {
| logger.error("", e);
| throw e;
| } finally {
| jbpmContext.close();
| }
| }
|
|
|
| public class JbpmUtil {
| static Logger logger = Logger.getLogger(JbpmUtil.class);
| static private JbpmConfiguration jbpmConfiguration = null;
|
| synchronized static public JbpmConfiguration getJbpmConfig() {
| if (jbpmConfiguration == null) {
| jbpmConfiguration =
JbpmConfiguration.getInstance("jbpm.cfg.xml");
| }
|
[jboss-user] [JBoss jBPM] - Re: Stale state problem kills process instance?
i posted this as http://jira.jboss.com/jira/browse/JBPM-1027 View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4068418#4068418 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4068418 ___ jboss-user mailing list jboss-user@lists.jboss.org https://lists.jboss.org/mailman/listinfo/jboss-user
[jboss-user] [JBoss jBPM] - Re: Stale state problem kills process instance?
We're working on reproducing this in the simplest manner possible. so far it seems not to happen on HSQL. i didnt want to add it in as a jira ticket until i was sure it wasnt just a configuration blunder. here are the steps we took though to reproduce the issue: 1. jbpm 3.2.1 deployed from the available EAR onto JBoss AS 4.0.5GA (on another machine we just have the console war and the behaviour is the same) 2. postgres 8.2 3. JDK 1.5 4. standard postgres jbpm-ds.xml 5. deploy the process, literally, Start->Fork->Join->End 6. start an instance from the web console We got a stacktrace with the remote debugger as below. The error seems to be that it is trying to update the version of the parent token using lock while it is executing the join. the hibernate code in the trace is trying to execute an update to increment the version of the token and receiving a 0 record count from the update. it thinks that means that the where clause failed and therefore it's looking for an obsolete version to update. if you still think this may be a bug as opposed to misconfiguration, i will enter a jira ticket for it. | 14:21:56,810 ERROR [STDERR] org.hibernate.StaleObjectStateException: Row was updated or deleted by another transaction (or unsaved-value mapping was incorrect): [org.jbpm.graph.exe.Token#41] | | at org.hibernate.persister.entity.AbstractEntityPersister.forceVersionIncrement(AbstractEntityPersister.java:1191) | | at org.hibernate.event.def.AbstractLockUpgradeEventListener.upgradeLock(AbstractLockUpgradeEventListener.java:82) | | at org.hibernate.event.def.DefaultLockEventListener.onLock(DefaultLockEventListener.java:64) | | at org.hibernate.impl.SessionImpl.fireLock(SessionImpl.java:584) | | at org.hibernate.impl.SessionImpl.lock(SessionImpl.java:576) | | at org.jbpm.graph.node.Join.execute(Join.java:110) | | at org.jbpm.graph.def.Node.enter(Node.java:318) | | at sun.reflect.GeneratedMethodAccessor222.invoke(Unknown Source) | | at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) | | at java.lang.reflect.Method.invoke(Method.java:585) | | at org.hibernate.proxy.pojo.cglib.CGLIBLazyInitializer.invoke(CGLIBLazyInitializer.java:185) | | at org.jbpm.graph.def.Node$$EnhancerByCGLIB$$205a4b1d.enter() | | at org.jbpm.graph.def.Transition.take(Transition.java:151) | | at org.jbpm.graph.def.Node.leave(Node.java:393) | | at org.jbpm.graph.def.Node.leave(Node.java:357) | | at org.jbpm.graph.node.Fork.execute(Fork.java:142) | | at org.jbpm.graph.def.Node.enter(Node.java:318) | | at sun.reflect.GeneratedMethodAccessor222.invoke(Unknown Source) | | at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) | | at java.lang.reflect.Method.invoke(Method.java:585) | | at org.hibernate.proxy.pojo.cglib.CGLIBLazyInitializer.invoke(CGLIBLazyInitializer.java:185) | | at org.jbpm.graph.def.Node$$EnhancerByCGLIB$$205a4b1d.enter() | | at org.jbpm.graph.def.Transition.take(Transition.java:151) | | at org.jbpm.graph.def.Node.leave(Node.java:393) | | at org.jbpm.graph.node.StartState.leave(StartState.java:70) | | 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:585) | | at org.hibernate.proxy.pojo.cglib.CGLIBLazyInitializer.invoke(CGLIBLazyInitializer.java:185) | | at org.jbpm.graph.def.Node$$EnhancerByCGLIB$$205a4b1d.leave() | | at org.jbpm.graph.exe.Token.signal(Token.java:194) | | at org.jbpm.graph.exe.Token.signal(Token.java:165) | | at org.jbpm.jsf.core.action.StartProcessActionListener.handleAction(StartProcessActionListener.java:70) | | at org.jbpm.jsf.core.impl.JbpmActionListenerWrapper.processAction(JbpmActionListenerWrapper.java:82) | | at javax.faces.event.ActionEvent.processListener(ActionEvent.java:77) | | at javax.faces.component.UIComponentBase.broadcast(UIComponentBase.java:758) | | at javax.faces.component.UICommand.broadcast(UICommand.java:368) | | at javax.faces.component.UIViewRoot.broadcastEvents(UIViewRoot.java:448) | | at javax.faces.component.UIViewRoot.processApplication(UIViewRoot.java:752) | | at com.sun.faces.lifecycle.InvokeApplicationPhase.execute(InvokeApplicationPhase.java:97) | | at com.sun.faces.lifecycle.LifecycleImpl.pha
[jboss-user] [JBoss jBPM] - Re: Stale state problem kills process instance?
Matthew, Can you create a unit test that shows this problem and attach it to a JIRA issue? Cheers, Koen View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4068127#4068127 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4068127 ___ jboss-user mailing list jboss-user@lists.jboss.org https://lists.jboss.org/mailman/listinfo/jboss-user
[jboss-user] [JBoss jBPM] - Re: Stale state problem kills process instance?
I was continuing to simplify this case and took out first one node and then the other - resulting in: | Start || | Fork || | Join || | End | and am continuing to have the same error. So far, flows with no fork seem to work. These are other related results: S=start;F=Fork;FA=asynch fork;N=node;NA=asynch node;J=join;E=end | S--F--J--ESTALE | S--FA--J--E NO ERROR | S--F--N--J--E STALE | S--FA--N--J--E NO ERROR | S--FA--(N1, N2)--J--E NPE as below | S--FA--(NA1, NA2)--J--E NPE as below | | HTTP Status 500 - | | type Exception report | | message | | description The server encountered an internal error () that prevented it from fulfilling this request. | | exception | | javax.servlet.ServletException | javax.faces.webapp.FacesServlet.service(FacesServlet.java:256) | org.jboss.web.tomcat.filters.ReplyHeaderFilter.doFilter(ReplyHeaderFilter.java:96) | | root cause | | java.lang.NullPointerException | java.lang.String.compareTo(String.java:998) | java.lang.String.compareTo(String.java:90) | org.jboss.gravel.data.action.SortActionListener$ELComparator.compare(SortActionListener.java:144) | java.util.Arrays.mergeSort(Arrays.java:1284) | java.util.Arrays.sort(Arrays.java:1223) | java.util.Collections.sort(Collections.java:159) | edu.emory.mathcs.backport.java.util.Collections.sort(Collections.java:31) | org.jboss.gravel.data.action.SortActionListener.processAction(SortActionListener.java:83) | javax.faces.event.ActionEvent.processListener(ActionEvent.java:77) | javax.faces.component.UIComponentBase.broadcast(UIComponentBase.java:758) | javax.faces.component.UICommand.broadcast(UICommand.java:368) | org.jboss.gravel.action.handler.ResponseActionsHandler.onComponentPopulated(ResponseActionsHandler.java:24) | com.sun.facelets.tag.jsf.ComponentHandler.apply(ComponentHandler.java:180) | com.sun.facelets.tag.CompositeFaceletHandler.apply(CompositeFaceletHandler.java:47) | com.sun.facelets.tag.jsf.ComponentHandler.applyNextHandler(ComponentHandler.java:314) | com.sun.facelets.tag.jsf.ComponentHandler.apply(ComponentHandler.java:169) | com.sun.facelets.tag.CompositeFaceletHandler.apply(CompositeFaceletHandler.java:47) | com.sun.facelets.tag.jsf.ComponentHandler.applyNextHandler(ComponentHandler.java:314) | com.sun.facelets.tag.jsf.ComponentHandler.apply(ComponentHandler.java:169) | org.jboss.gravel.common.handler.CollectionHandler.applyNextHandler(CollectionHandler.java:155) | com.sun.facelets.tag.jsf.ComponentHandler.apply(ComponentHandler.java:169) | com.sun.facelets.tag.CompositeFaceletHandler.apply(CompositeFaceletHandler.java:47) | com.sun.facelets.tag.jsf.ComponentHandler.applyNextHandler(ComponentHandler.java:314) | com.sun.facelets.tag.jsf.ComponentHandler.apply(ComponentHandler.java:169) | com.sun.facelets.tag.CompositeFaceletHandler.apply(CompositeFaceletHandler.java:47) | com.sun.facelets.tag.jsf.ComponentHandler.applyNextHandler(ComponentHandler.java:314) | com.sun.facelets.tag.jsf.ComponentHandler.apply(ComponentHandler.java:169) | com.sun.facelets.compiler.NamespaceHandler.apply(NamespaceHandler.java:49) | com.sun.facelets.compiler.EncodingHandler.apply(EncodingHandler.java:25) | com.sun.facelets.impl.DefaultFacelet.include(DefaultFacelet.java:248) | com.sun.facelets.impl.DefaultFacelet.include(DefaultFacelet.java:294) | com.sun.facelets.impl.DefaultFacelet.include(DefaultFacelet.java:273) | com.sun.facelets.impl.DefaultFaceletContext.includeFacelet(DefaultFaceletContext.java:143) | com.sun.facelets.tag.ui.DecorateHandler.apply(DecorateHandler.java:105) | com.sun.facelets.tag.CompositeFaceletHandler.apply(CompositeFaceletHandler.java:47) | com.sun.facelets.tag.jsf.ComponentHandler.applyNextHandler(ComponentHandler.java:314) | com.sun.facelets.tag.jsf.ComponentHandler.apply(ComponentHandler.java:169) | com.sun.facelets.tag.CompositeFaceletHandler.apply(CompositeFaceletHandler.java:47) | com.sun.facelets.tag.jsf.ComponentHandler.applyNextHandler(ComponentHandler.java:314) | com.sun.facelets.tag.jsf.ComponentHandler.apply(ComponentHandler.java:169) | com.sun.facelets.tag.ui.DefineHandler.apply(DefineHandler.java:58) | com.sun.facelets.tag.ui.CompositionHandler.apply(CompositionHandler.java:128) | com.sun.facelets.impl.DefaultFaceletContext$TemplateManager.apply(DefaultFaceletContext.java:306) | com.sun.facelets.impl.DefaultFaceletContext.includeDefinition(DefaultFaceletContext.java:279) | com.sun.facelets.tag.ui.InsertHandler.apply(InsertHandler.java:68) | com.sun.facelets.tag.CompositeFaceletHandler.apply(CompositeFaceletHandler.java:47) | com.sun.facelets.compiler.NamespaceHandler.apply(Names
