[jBPM Users] - Re: Same token seems to be attached to two task instances?
by gfargone
Ronald,
I was suspecting a transaction rollback also, but it turns out that one clever user has wondered onto the page where you can manually move between tasks in a process using the native jbpm-console. Doing that totally messes up things as it leaves the original task open.
We used to link to the native console to show the current process image and the current active task. It turns out there is no way to clamp down permissions sufficiently using the properties file provided.
The solution was to eliminate all access to the native console except for a few admins who understand how to use it. We just serve up the static process image retrieved from the process definition file through a little servlet and the user has to locate the task name on it. The current task name is provided in a small pop up screen.
This incident gave me serious grief and I never seen it in the development environment. We are using JBPM in a production pilot at this point.
Thanks,
Tamas
View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4254861#4254861
Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=4254861
16 years, 7 months
[jBPM Users] - Transition Timers Not Marking a Task as Complete
by jnlugo
I have a timer on a transition in task A. When the timer fires in task A, the task follows the transition to the next task, B. However, task A is not considered complete when the timer fires and moves the task. So when I query for tasks for users assigned to task A, the task that is now in B is returned.
Is there a good way to mark task A as complete when the timer fires? I haven't had much luck with event listeners.
<process name="MyProcess" xmlns="http://jbpm.org/4.0/jpdl">
| <start name="start1">
| <transition name="to review" to="TaskA"/>
| </start>
| <task candidate-groups="#{status.taskAGroups}" name="TaskA">
| <transition name="forward" to="TaskB">
| <timer duedate="#{status.timeout}"/>
| </transition>
| </task>
| <task candidate-groups="#{status.taskBGroups}" name="TaskB">
| <transition name="forward" to="EndState"/>
| </task>
| <end name="Final" state="EndState"/>
| </process>
View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4254859#4254859
Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=4254859
16 years, 7 months
[jBPM Users] - Re: jBPM 4 and thread-safeness
by greeneagle
First of all thanks for the fast response :-)
If this is the wrong forum for this kind of question could you please move the thread to the dev-forum? ...because I still have some questions concerning this issue.
anonymous wrote :
| in strickt java sense, nutable methods on threadsafe objects should be synchronized. in jbpm sense, the only requirement is that you don't change your member fields in the execute method.
|
I totally agree to that approach. It's the same as the singleton-model in spring. The threadsafeness (even more: reintrance) is guaranteed if the developer observes some basic rules. If he does not strange things may occur.
anonymous wrote :
| in jbpm 4, we want to get to a situation that the event listener object becomes a part of the process definition object graph. and hence it gets cached and used by all threads
|
How can you handle this? IMHO this strategy only can work if the member variables of a handler-impl are set with constant values. Since it is possible to inject dynamic values in a member-var (e.g. return values from a prior method-call) it will have the same effect than changing the member fields in the handler-class itself.
For better explanation of what I mean a short piece of code (sorry it is JBPM 3-style but I am atm still a rookie in JBPM 4 :-( )
| // in class A I create a ProcessDefinition
| ProcessDefinition pd = new ProcessDefinition(...);
|
| // now I start a couple of instances of class B (which extend Thread)
| // and start the threads
| for(int i = 0; i < 100; i++) {
| new B(pd).start();
| }
|
| // class B looks something like that:
| public class B extends Thread {
|
| private ProcessDefinition pd;
|
| public B(ProcessDefinition pd) {
| this.pd = pd;
| }
|
| public void run() {
| //Note that I start the ProcessInstance depending on the same ProcessDefinition-instance
| ProcessInstance pi = new ProcessInstance(this.pd);
| pi.signal();
| }
| }
|
In JBPM 3 an action-delegate was instantiated at first access. After that the already instantiated object was used:
| // snippet from Delegation
| public Object getInstance() {
| if (instance==null) {
| instance = instantiate();
| }
| return instance;
| }
|
So if I understood you right the behaviour must be the same than in JBPM 4 after the point of the instantiation of the delegate.
This code produces the result I explained before:
If the member-fields of the used handlers are only set with constant values everything works fine
If the member-fields are set dynamically (e.g. via expressions) it becomes broken
And now the big question:
Have I understood something wrong or is this kind of test-scenario (multiple threads using the same ProcessDefinition-instance for instantiating ProcessDefinitions a kind of operation outside the specification?
View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4254836#4254836
Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=4254836
16 years, 7 months
[jBPM Users] - Re: Signaling executions for processes that containt tasks d
by LMarinkov
/*
| * JBoss, Home of Professional Open Source
| * Copyright 2005, JBoss Inc., and individual contributors as indicated
| * by the @authors tag. See the copyright.txt in the distribution for a
| * full listing of individual contributors.
| *
| * This is free software; you can redistribute it and/or modify it
| * under the terms of the GNU Lesser General Public License as
| * published by the Free Software Foundation; either version 2.1 of
| * the License, or (at your option) any later version.
| *
| * This software is distributed in the hope that it will be useful,
| * but WITHOUT ANY WARRANTY; without even the implied warranty of
| * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU
| * Lesser General Public License for more details.
| *
| * You should have received a copy of the GNU Lesser General Public
| * License along with this software; if not, write to the Free
| * Software Foundation, Inc., 51 Franklin St, Fifth Floor, Boston, MA
| * 02110-1301 USA, or see the FSF site: http://www.fsf.org.
| */
| package org.jbpm.test.history;
|
| import java.util.Map;
|
| import org.jbpm.api.Execution;
| import org.jbpm.test.JbpmTestCase;
|
|
| /**
| * @author Tom Baeyens
| */
| public class AvgDurationTest extends JbpmTestCase {
|
| public void testAvgDuration() throws Exception {
| deployJpdlXmlString(
| "<process name='Insurance claim' key='ICL'>" +
| " <start>" +
| " <transition to='one' />" +
| " </start>" +
| " <task name='one'>" +
| " <transition to='two' />" +
| " </task>" +
| " <task name='two'>" +
| " <transition to='three' />" +
| " </task>" +
| " <task name='three'>" +
| " <transition to='end' />" +
| " </task>" +
| " <end name='end' />" +
| "</process>"
| );
|
| executeProcess();
| executeProcess();
| executeProcess();
|
| Map<String, Long> avgDurations = historyService.avgDurationPerActivity("ICL-1");
|
|
| Long avgDurationOne = avgDurations.get("one");
| assertNotNull(avgDurationOne);
| assertTrue("expected avg duration bigger then 40, but was"+avgDurationOne, avgDurationOne>40);
| Long avgDurationTwo = avgDurations.get("two");
| assertNotNull(avgDurationTwo);
| assertTrue("expected avg duration bigger then 10, but was"+avgDurationTwo, avgDurationTwo>10);
| Long avgDurationThree = avgDurations.get("three");
| assertNotNull(avgDurationThree);
| assertTrue("expected avg duration bigger then 0, but was"+avgDurationThree, avgDurationThree>=0);
|
| assertEquals(3, avgDurations.size());
| }
|
| protected void executeProcess() throws InterruptedException {
| Execution execution = executionService.startProcessInstanceByKey("ICL");
| Thread.sleep(50);
| executionService.signalExecutionById(execution.getId());
| Thread.sleep(20);
| executionService.signalExecutionById(execution.getId());
| executionService.signalExecutionById(execution.getId());
| }
|
| }
View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4254816#4254816
Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=4254816
16 years, 7 months