September 2007 - jboss-jira - Jboss List Archives

[JBoss JIRA] Closed: (JBPM-633) Asynchronous Action Handler required for async continuations

by Tom Baeyens (JIRA)

[ http://jira.jboss.com/jira/browse/JBPM-633?page=all ] Tom Baeyens closed JBPM-633. ---------------------------- Resolution: Duplicate Issue i believe this will be fixed in 3.2.2. See also JBPM-995 > Asynchronous Action Handler required for async continuations > ------------------------------------------------------------ > > Key: JBPM-633 > URL: http://jira.jboss.com/jira/browse/JBPM-633 > Project: JBoss jBPM > Issue Type: Feature Request > Components: Core Engine > Affects Versions: jBPM 3.1 > Reporter: Mark Shotton > Assigned To: Tom Baeyens > > As there is only a single CommandExecutorThread on which all async ActionHandler execute methods are called, it is important to write execute methods that run asynchronously when these may be long running; otherwise the CommandExecutorThread is held up from processing other actions. > This presents a thread safety problem. The problem lies in beginning a new transaction from within the ActionHandler execute method; e.g. > (1) Prior to executing an action, the JBPM framework opens a new JbpmContext and locks the token. > (2) The framework executes the action by calling ActionHandler.execute(ExecutionContext executionContext); the ExecutionContext provides access to the JbpmContext opened by the framework. > (3) I start a new thread from within the execute method to execute asynchronously. > (4) The execute method exits and the framework saves and closes the original JbpmContext and token > (5) The new thread opens a second JbpmContext and finds and progresses the token (this being possible even if the framework has not unlocked its token yet because the new thread gets a new copy of the token that is not locked; tokens are locked in memory; not at a database level). > (6) The new thread saves and closes the second JbpmContext. > The problem arises when the framework attempts to save a token that has already been progressed by the new thread; or the new thread tries to progress a token that has since been updated by the framework ? we have a race condition. > I think that there are a couple of obvious solutions: > (1) As a work-around, the execute method starts the new thread and then sets a context variable in the process instance ? this will not be saved to the database until the framework closes its JbpmContext. The asynchronous thread sleeps until the process instance has the context variable set before progressing the token. > (2) The JBPM framework examines the class of the ActionHandler before calling its execute method; if it is an instance of an AsyncActionHandler, the framework gets the process instance ID and task instance ID from the token and then saves and closes its JbpmContext. It then calls the execute method of the AsyncActionHandler, passing in the process instance ID and task instance ID (the latter may be null) instead of the ExecutionContext. > I think that the latter solution or something like it would be a very useful addition to the JBPM framework. -- 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

18 years, 10 months

1
0
0 / 0

[JBoss JIRA] Created: (JBPM-1032) task-assign-events are sometimes fired when group assignment is performed

by Karsten Dello (JIRA)

task-assign-events are sometimes fired when group assignment is performed ------------------------------------------------------------------------- Key: JBPM-1032 URL: http://jira.jboss.com/jira/browse/JBPM-1032 Project: JBoss jBPM Issue Type: Bug Components: Core Engine Affects Versions: jBPM jPDL 3.2.1 Reporter: Karsten Dello Assigned To: Tom Baeyens A "task-assingn"-event is sometimes fired, if only group assignment (setting pooledActors) is performed. This always happens when a swimlane is in use which specifies pooled-actors (junit test 1). On the other hand, when the pooled-actors are expressed via an assignment-element as an child element of a task (junit test 2), the event is not fired. >From my point of view the engine should either: a) not fire an task-assign-event in case of group assignments at all b) fire it consequently at all group assignments events c) fire a different event Ronald suggested in the forum thread (link above) to introduce a seperate event "task-group-assign" in case a task gets assigned to a group. In my opinion this would be the best solution to this problem. public void testTaskAssignIsFiredWithSwimlaneGroupAssignment() { ProcessDefinition processDefinition = ProcessDefinition.parseXmlString( "<process-definition name=\"someprocessxyz\">" + " <event type=\"task-assign\">" + " <script>System.out.println(\"task-assign-event fired!\");" + " executionContext.setVariable(\"task-assign-event-has-fired\",Boolean.TRUE);</script>"+ " </event>"+ " <start-state>" + " <transition to='a' />" + " </start-state>" + " <swimlane name='swimlane22'>"+ " <assignment pooled-actors='jan,nina'/>"+ " </swimlane>"+ " <task-node name='a'>" + " <task name='sometask' swimlane='swimlane22'/>" + " <transition to='end'/>"+ " </task-node>"+ " <end-state name='end' />" + "</process-definition>" ); ProcessInstance processInstance = new ProcessInstance(processDefinition); Token token = processInstance.getRootToken(); processInstance.signal(); Object o=processInstance.getContextInstance().getVariable("task-assign-event-has-fired"); assertEquals(Boolean.TRUE, o); } public void testTaskAssignIsNOTFiredWithSwimlaneGroupAssignment() { ProcessDefinition processDefinition = ProcessDefinition.parseXmlString( "<process-definition name=\"someprocessxyz\">" + " <event type=\"task-assign\">" + " <script>System.out.println(\"task-assign-event fired!\")"+ " executionContext.setVariable(\"task-assign-event-has-fired\",Boolean.TRUE);</script>"+ " </event>"+ " <start-state>" + " <transition to='a' />" + " </start-state>" + " <task-node name='a'>" + " <task name='sometask'>" + " <assignment pooled-actors='jan,nina'/>"+ " </task>"+ " <transition to='end'/>"+ " </task-node>"+ " <end-state name='end' />" + "</process-definition>" ); ProcessInstance processInstance = new ProcessInstance(processDefinition); Token token = processInstance.getRootToken(); processInstance.signal(); Object o=processInstance.getContextInstance().getVariable("task-assign-event-has-fired"); assertEquals(Boolean.TRUE, o); } -- 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

18 years, 10 months

2
2
0 / 0

[JBoss JIRA] Created: (JBPM-1033) string_max parameterization doesn't work

by tmullett (JIRA)

string_max parameterization doesn't work ----------------------------------------- Key: JBPM-1033 URL: http://jira.jboss.com/jira/browse/JBPM-1033 Project: JBoss jBPM Issue Type: Bug Components: Core Engine Affects Versions: jBPM jPDL 3.2.1 Environment: WIndows XP, Hibernate 3.2.4.sp1, Java 1.4.2 Reporter: tmullett Assigned To: Tom Baeyens Fields in the hibernate mapping files declared as type "string_max" should be truncated to the parameterized length. The mapping files do this parameterization with a "length" attribute on the property element. It looks like this (from ActionLog.hbm.xml): <property name="exception" type="string_max" column="EXCEPTION_" length="4000" /> 4000 also happens to be what StringMax will use if it can't find or parse its parameterization. We needed to shorten some fields to fit jBpm into MS SQL Server. When we shortened the length, we noticed that the parameter was being ignored, causing jdbc to blow chunks. org.jbpm.db.hibernate.StringMax.setParameterValues() always gets a null passed in for it's parameters with this setup. To get it to work , we changed it to <property name="exception" column="EXCEPTION_"> <type name="string_max"> <param name="length">1000</param> </type> </property> -- 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

18 years, 10 months

3
4
0 / 0

[JBoss JIRA] Updated: (JBPM-165) process instance versioning

by Tom Baeyens (JIRA)

[ http://jira.jboss.com/jira/browse/JBPM-165?page=all ] Tom Baeyens updated JBPM-165: ----------------------------- Fix Version/s: jBPM jPDL 3.2.3 (was: jBPM jPDL 3.2.2) > process instance versioning > --------------------------- > > Key: JBPM-165 > URL: http://jira.jboss.com/jira/browse/JBPM-165 > Project: JBoss jBPM > Issue Type: Feature Request > Components: Core Engine > Reporter: Tom Baeyens > Assigned To: Tom Baeyens > Fix For: jBPM jPDL 3.2.3 > > > i think jbpm could offer some degree of assistence in process instance versioning. > when a new version of a process is deployed, jbpm could do the following conversion for a process instance : > * input required: mapping of the nodes from the old to the new definition. > * cancel the old process instance > * create a new process instance and copy the runtime (exe) information such as tokens and process variables from the old process instance. > * then establish a special link between the 2 process instances to indicate that the new process instance is the continuation of the old process instance. > this way we can avoid the problematic conversion of logs, while still keeping them in the system. -- 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

18 years, 10 months

1
0
0 / 0

[JBoss JIRA] Created: (JBPM-985) process execution stops without notice if late-bound sub-process is missing

by Alexander Schlett (JIRA)

process execution stops without notice if late-bound sub-process is missing --------------------------------------------------------------------------- Key: JBPM-985 URL: http://jira.jboss.com/jira/browse/JBPM-985 Project: JBoss jBPM Issue Type: Bug Components: Core Engine Affects Versions: jBPM jPDL 3.2 Environment: hypersonic in-memory database Reporter: Alexander Schlett Assigned To: Tom Baeyens No error or warning is logged if sub-process is not deployed. Only a debug message on deployment of the parent process states that the subprocess is not bound (late-binding). Process execution stops then if process-state with missing sub-process definition is reached. At least there should be something in the logs. -- 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

18 years, 10 months

2
2
0 / 0

[JBoss JIRA] Created: (JBPM-972) org.jbpm.graph.action.Script does not provide specific (correct) handling for bsh.TargetError

by Olga Ivanova (JIRA)

org.jbpm.graph.action.Script does not provide specific (correct) handling for bsh.TargetError --------------------------------------------------------------------------------------------- Key: JBPM-972 URL: http://jira.jboss.com/jira/browse/JBPM-972 Project: JBoss jBPM Issue Type: Bug Components: Core Engine Affects Versions: jBPM jPDL 3.2 Reporter: Olga Ivanova Assigned To: Tom Baeyens The recommended way of handling beanshel script TargerError is to use target exception (rethrow or printout), instead of using TargerError itself. see (http://www.beanshell.org/manual/bshmanual.html). The reason why this problem is reported is that when TargetError is not handled in a way it is proposed, stack trace where such error exists became inaccurate. This happends if TargetError is a cause for some other error on which printStackTrace is called, and TargetError itself contains targer exception with it's own causes. In this case, only target exception itself is printed out, all it's cause exceptions are not printed. Unit Test is attached. In JBPM org.jbpm.graph.action.Script , following code handles beanshell script exceptions (line 137): } catch (EvalError e) { log.warn("exception during evaluation of script expression", e); // try to throw the cause of the EvalError if (e.getCause() instanceof Exception) { throw (Exception) e.getCause(); } else if (e.getCause() instanceof Error) { throw (Error) e.getCause(); } else { throw e; } } Which does not work as expected, as TargerError which extends EvalError always returns null from getCause method. Another thing is that there are two child classes of EvalError - TargetError, which should be handled specially and ParseException, where no special handling is required. The correct way of handling these exceptions could be following: } catch (EvalError e) { log.warn("exception during evaluation of script expression", e); if (e instanceof TargetError) { TargetError te = (TargetError)e; // try to throw the cause of the TargetError if (te.getTarget() instanceof Exception) { throw (Exception) te.getTarget(); } else if (te.getTarget() instanceof Error) { throw (Error) te.getTarget(); } } throw e; -- 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

18 years, 10 months

2
3
0 / 0

[JBoss JIRA] Closed: (JBPM-653) make the process parent classloader configurable

by Tom Baeyens (JIRA)

[ http://jira.jboss.com/jira/browse/JBPM-653?page=all ] Tom Baeyens closed JBPM-653. ---------------------------- Fix Version/s: (was: jBPM jPDL 3.2.2) Resolution: Rejected will only be fixed in 4.0 > make the process parent classloader configurable > ------------------------------------------------ > > Key: JBPM-653 > URL: http://jira.jboss.com/jira/browse/JBPM-653 > Project: JBoss jBPM > Issue Type: Feature Request > Components: Core Engine > Reporter: Tom Baeyens > Assigned To: Tom Baeyens > > now, always the jBPM classloader is taken as a parent for the process classloaders. this should be made configurable. at least one other possibility should be to configure the context classloader. -- 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

18 years, 10 months

1
0
0 / 0

[JBoss JIRA] Resolved: (BPEL-190) webservice descriptors generation tool

by Alejandro Guizar (JIRA)

[ http://jira.jboss.com/jira/browse/BPEL-190?page=all ] Alejandro Guizar resolved BPEL-190. ----------------------------------- Resolution: Done developed tools to generate webservices.xml and web.xml automatically > webservice descriptors generation tool > -------------------------------------- > > Key: BPEL-190 > URL: http://jira.jboss.com/jira/browse/BPEL-190 > Project: JBoss jBPM BPEL > Issue Type: Task > Security Level: Public(Everyone can see) > Components: Engine > Reporter: Alejandro Guizar > Assigned To: Alejandro Guizar > Fix For: jBPM BPEL 1.1 GA > > > create a tool for generating web application artifacts -- 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

18 years, 10 months

1
0
0 / 0

[JBoss JIRA] Created: (JBRULES-779) Better error reporting in the GUI

by Michael Neale (JIRA)

Better error reporting in the GUI --------------------------------- Key: JBRULES-779 URL: http://jira.jboss.com/jira/browse/JBRULES-779 Project: JBoss Rules Issue Type: Sub-task Security Level: Public (Everyone can see) Reporter: Michael Neale Assigned To: Michael Neale -- 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

18 years, 10 months

1
3
0 / 0

[JBoss JIRA] Created: (JBMESSAGING-1054) Create a test where a client failing with a ClusteredCF

by Clebert Suconic (JIRA)

Create a test where a client failing with a ClusteredCF ------------------------------------------------------- Key: JBMESSAGING-1054 URL: http://jira.jboss.com/jira/browse/JBMESSAGING-1054 Project: JBoss Messaging Issue Type: Task Reporter: Clebert Suconic Assigned To: Clebert Suconic Fix For: 1.4.0.GA -- 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

18 years, 10 months

1
1
0 / 0

2026

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

jboss-jira September 2007