[JBoss JIRA] Created: (JBPM-1991) Change default parentLockMode from FORCE to UPGRADE
by Alejandro Guizar (JIRA)
Change default parentLockMode from FORCE to UPGRADE
---------------------------------------------------
Key: JBPM-1991
URL: https://jira.jboss.org/jira/browse/JBPM-1991
Project: JBoss jBPM
Issue Type: Task
Security Level: Public (Everyone can see)
Components: Core Engine
Reporter: Alejandro Guizar
Fix For: jBPM-3.2.4.SP1, jBPM 3.2.6 GA
According to the Hibernate documentation, LockMode.FORCE is "similar to UPGRADE except that, for versioned entities, it results in a forced version increment". The version increment often produces undue stale state exceptions under databases that support isolation levels above READ_UNCOMMITTED, i.e. all except HSQLDB.
Under HSQLDB, LockMode.FORCE provides a simplistic work-around the lack of isolation. Unfortunately it does not constitute a real solution since dirty reads can occur anywhere else, causing all kinds of "weird" assertion failures. Every test case that exercises concurrency has been excluded from the HSQLDB test suite due to its unreliability.
Therefore, no reason remains to keep the default parentLockMode at FORCE.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
15 years, 9 months
[JBoss JIRA] Created: (JBPM-1185) Node, State and ProcessState don't support Conditions on Transitions
by Britt Miner (JIRA)
Node, State and ProcessState don't support Conditions on Transitions
--------------------------------------------------------------------
Key: JBPM-1185
URL: http://jira.jboss.com/jira/browse/JBPM-1185
Project: JBoss jBPM
Issue Type: Bug
Components: Core Engine
Affects Versions: jBPM jPDL 3.2.2
Reporter: Britt Miner
Assigned To: Tom Baeyens
Node, State, and ProcessState don't provide any preliminary check for conditions provided on transitions. No check is performed until the transition is signaled, at which point the process will barf if a condition is present on the default transition, and that condition evaluates to false.
Regardless if a person "should" be using transition conditions in Node or State, the schema allows it, the documentation doesn't forbid it, and the current behavior of a Transition element in the jpdl is inconsistent. The fix to make everything consistent is fairly simple--only org.jbpm.graph.def.Node needs to really be altered (and a one-liner in ProcessState):
In org.jbpm.graph.def.Node, add the following method:
// BRITT--
public Transition calculateLeavingTransition(ExecutionContext executionContext) {
Transition transition = null;
boolean hasTransitioned = false;
Iterator iter = leavingTransitions.iterator();
while (iter.hasNext()) {
Transition candidate = (Transition) iter.next();
String conditionExpression = candidate.getCondition();
if (conditionExpression != null) {
Object result = JbpmExpressionEvaluator.evaluate(conditionExpression, executionContext);
if (Boolean.TRUE.equals(result)) {
transition = candidate;
}
} else {
transition = candidate;
}
}
if (!hasTransitioned) {
this.getDefaultLeavingTransition().removeConditionEnforcement();
log.warn("All transition conditions have evaluated to 'false'. Taking the default transition.");
transition = this.getDefaultLeavingTransition();
}
return transition;
}
// --BRITT
...and modify "leave(ExecutionContext executionContext)":
// BRITT --replace the following line with the code below
// to check conditions before selecting the transition to take...
//leave(executionContext, getDefaultLeavingTransition()); //original line
leave(executionContext, calculateLeavingTransition(executionContext));
// --BRITT
For consistency, ProcessState should also have one line modified at the very end of it's "leave(ExecutionContext, Transition)" method:
// BRITT-- rather than specify which transition, let the super class decide...
//super.leave(executionContext, getDefaultLeavingTransition());
super.leave(executionContext, calculateLeavingTransition(executionContext));
// --BRITT
--
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
15 years, 9 months
[JBoss JIRA] Commented: (JBPM-2043) Add jBPM performance test coverage
by Alejandro Guizar (JIRA)
[ https://jira.jboss.org/jira/browse/JBPM-2043?page=com.atlassian.jira.plug... ]
Alejandro Guizar commented on JBPM-2043:
----------------------------------------
Results after the improvements.
[aguizar@siankaan core]$ mvn -Dtest=SimplePerformanceTest test
Running org.jbpm.perf.SimplePerformanceTest
=== Test finished processing 1000 instances in 4840ms ===
=== This is 207 instances per second ===
Tests run: 1, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 18.159 sec
Running org.jbpm.perf.SimplePerformanceTest
=== Test finished processing 1000 instances in 4282ms ===
=== This is 234 instances per second ===
Tests run: 1, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 17.779 sec
Running org.jbpm.perf.SimplePerformanceTest
=== Test finished processing 1000 instances in 4342ms ===
=== This is 230 instances per second ===
Tests run: 1, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 17.88 sec
Seems like 3.2.5 performs even better than 3.2.2. I've pointed the jbpm-2043 build back to the branches.
> Add jBPM performance test coverage
> ----------------------------------
>
> Key: JBPM-2043
> URL: https://jira.jboss.org/jira/browse/JBPM-2043
> Project: JBoss jBPM
> Issue Type: Task
> Security Level: Public(Everyone can see)
> Components: Productization
> Affects Versions: jBPM 3.2.5 GA
> Environment: SOA 4.3.0 CP01 CR2
> Reporter: Pavel Macik
> Assignee: Alejandro Guizar
> Fix For: jBPM-3.2.5.SP2, jBPM 3.2.6 GA
>
>
> Performance of jBPM has dropped significantly according to
> http://hudson.qa.jboss.com/hudson/view/SOA-Performance/job/SOA-Platform-P...
> Other performance has not changed much so the performance drop is isolated to jBPM.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
15 years, 10 months
[JBoss JIRA] Commented: (JBPM-2043) Add jBPM performance test coverage
by Alejandro Guizar (JIRA)
[ https://jira.jboss.org/jira/browse/JBPM-2043?page=com.atlassian.jira.plug... ]
Alejandro Guizar commented on JBPM-2043:
----------------------------------------
I modified Martin's latest test to perform some warmup before measuring. Here are my results before any improvement to 3.2.5.SP.
jbpm-3.2.5.SP/modules/core
[aguizar@siankaan core]$ mvn -Dtest=SimplePerformanceTest test
Running org.jbpm.perf.SimplePerformanceTest
=== Test finished processing 1000 instances in 7029ms ===
=== This is 142 instances per second ===
Tests run: 1, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 19.924 sec
Running org.jbpm.perf.SimplePerformanceTest
=== Test finished processing 1000 instances in 6610ms ===
=== This is 151 instances per second ===
Tests run: 1, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 19.644 sec
Running org.jbpm.perf.SimplePerformanceTest
=== Test finished processing 1000 instances in 6200ms ===
=== This is 161 instances per second ===
Tests run: 1, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 19.102 sec
jpdl-3.2.2-SOA-4.2/jpdl/jar
[aguizar@siankaan jar]$ ant -Dtest=org.jbpm.perf.SimplePerformanceTest one-test
one-test:
[junit] Running org.jbpm.perf.SimplePerformanceTest
[junit] === Test finished processing 1000 instances in 5428ms ===
[junit] === This is 184 instances per second ===
[junit] Tests run: 1, Failures: 0, Errors: 0, Time elapsed: 35.804 sec
one-test:
[junit] Running org.jbpm.perf.SimplePerformanceTest
[junit] === Test finished processing 1000 instances in 5123ms ===
[junit] === This is 195 instances per second ===
[junit] Tests run: 1, Failures: 0, Errors: 0, Time elapsed: 35.422 sec
one-test:
[junit] Running org.jbpm.perf.SimplePerformanceTest
[junit] === Test finished processing 1000 instances in 4965ms ===
[junit] === This is 201 instances per second ===
[junit] Tests run: 1, Failures: 0, Errors: 0, Time elapsed: 35.023 sec
Seems we do have a performance drop. On to improving 3.2.5.SP.
> Add jBPM performance test coverage
> ----------------------------------
>
> Key: JBPM-2043
> URL: https://jira.jboss.org/jira/browse/JBPM-2043
> Project: JBoss jBPM
> Issue Type: Task
> Security Level: Public(Everyone can see)
> Components: Productization
> Affects Versions: jBPM 3.2.5 GA
> Environment: SOA 4.3.0 CP01 CR2
> Reporter: Pavel Macik
> Assignee: Alejandro Guizar
> Fix For: jBPM-3.2.5.SP2, jBPM 3.2.6 GA
>
>
> Performance of jBPM has dropped significantly according to
> http://hudson.qa.jboss.com/hudson/view/SOA-Performance/job/SOA-Platform-P...
> Other performance has not changed much so the performance drop is isolated to jBPM.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
15 years, 10 months