[JBoss JIRA] Created: (JBPM-2202) jBPM might be re-loading classes when not strictly necessary
by Alejandro Guizar (JIRA)
jBPM might be re-loading classes when not strictly necessary
------------------------------------------------------------
Key: JBPM-2202
URL: https://jira.jboss.org/jira/browse/JBPM-2202
Project: JBoss jBPM
Issue Type: Bug
Security Level: Public (Everyone can see)
Components: Runtime Engine
Affects Versions: jBPM 3.2.5.SP5
Environment: 39 unique processes
243 entries in jbpm.jbpm_processdefinition
ach process has ~6 versions deployed, of which only the most recent version is in daily usage
ehcache is configured as the hibernate cache.
Reporter: Alejandro Guizar
Assignee: Alejandro Guizar
jBPM creates new Java classes out of binary process definition data stored in the database. This is needed for different versions of the process. It appears a special classloader is used for this. In SUN hotspot-class JVMs, parts of these load classes would be stored in perm gen rather than heap, which is not typically collected until absolutely necessary, potentially causing high cpu gc thrashing issues. If this was normal objects we were dealing with, the parallel scavenges or CMS fulls should collect them without problems. It appears this is not the case.
I believe the issue is that jBPM might be re-loading classes when not strictly necessary.
--
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
16 years, 9 months
[JBoss JIRA] Created: (JBPM-2230) jBPM failed the build with Maven 2.1.0 though there is no problem with Maven 2.0.9 or 2.0.10
by ryan zhang (JIRA)
jBPM failed the build with Maven 2.1.0 though there is no problem with Maven 2.0.9 or 2.0.10
--------------------------------------------------------------------------------------------
Key: JBPM-2230
URL: https://jira.jboss.org/jira/browse/JBPM-2230
Project: JBoss jBPM
Issue Type: Bug
Security Level: Public (Everyone can see)
Components: Console
Affects Versions: jBPM 3.2.5.SP5
Environment: mvn version
Apache Maven 2.1.0 (r755702; 2009-03-19 03:10:27+0800)
Java version: 1.5.0_18
Java home: /home/ryan/software/jdk1.5.0_18/jre
Default locale: en_US, platform encoding: UTF-8
OS name: "linux" version: "2.6.27.5-117.fc10.i686" arch: "i386" Family: "unix"
Reporter: ryan zhang
Run "mvn -Pdistro clean install" at jBPM check out folder.(version 3.2.5), the build will failed.
Error log attached and some part of information followed either:
[INFO] Building JBoss jBPM3 - Distribution
[INFO] task-segment: [clean, install]
[INFO] ------------------------------------------------------------------------
[INFO] [clean:clean]
[INFO] Deleting directory /home/ryan/workspace/soa-work/jbpm/checkout/modules/distribution/target
[INFO] [assembly:directory-single {execution: make-assembly}]
[INFO] Reading assembly descriptor: scripts/assembly-deploy-artifacts.xml
[INFO] Processing DependencySet (output=lib)
[WARNING] Cannot include project artifact: org.jbpm.jbpm3:jbpm-distribution:pom:3.2.5.SP5; it doesn't have an associated file or directory.
[INFO] Processing DependencySet (output=lib)
[WARNING] Cannot include project artifact: org.jbpm.jbpm3:jbpm-distribution:pom:3.2.5.SP5; it doesn't have an associated file or directory.
[INFO] Processing DependencySet (output=lib)
[WARNING] Cannot include project artifact: org.jbpm.jbpm3:jbpm-distribution:pom:3.2.5.SP5; it doesn't have an associated file or directory.
[INFO] Processing DependencySet (output=resources/jbpm-jpdl-config)
[WARNING] Cannot include project artifact: org.jbpm.jbpm3:jbpm-distribution:pom:3.2.5.SP5; it doesn't have an associated file or directory.
[INFO] Processing DependencySet (output=resources/jbpm-enterprise-config)
[WARNING] Cannot include project artifact: org.jbpm.jbpm3:jbpm-distribution:pom:3.2.5.SP5; it doesn't have an associated file or directory.
[INFO] Processing DependencySet (output=src)
[WARNING] Cannot include project artifact: org.jbpm.jbpm3:jbpm-distribution:pom:3.2.5.SP5; it doesn't have an associated file or directory.
[WARNING] The following patterns were never triggered in this artifact inclusion filter:
o 'org.jboss.jbpm:*:jar:sources'
[INFO] ------------------------------------------------------------------------
[ERROR] BUILD FAILURE
[INFO] ------------------------------------------------------------------------
[INFO] : org.apache.maven.plugin.assembly.model.Assembly@11aed03
Assembly is incorrectly configured: deploy-artifacts
Assembly: deploy-artifacts is not configured correctly: One or more filters had unmatched criteria. Check debug log for more information.
--
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
16 years, 9 months
[JBoss JIRA] Created: (JBPM-2040) Inconsistent behaviour depending on the ordering of events (fork+end state+join)
by Thomas Diesler (JIRA)
Inconsistent behaviour depending on the ordering of events (fork+end state+join)
--------------------------------------------------------------------------------
Key: JBPM-2040
URL: https://jira.jboss.org/jira/browse/JBPM-2040
Project: JBoss jBPM
Issue Type: Bug
Security Level: Public (Everyone can see)
Components: Core Engine
Affects Versions: jBPM 3.2.3
Reporter: Mauro Molinari
Assignee: Thomas Diesler
Given the following process definition:
<?xml version="1.0" encoding="UTF-8"?>
<process-definition xmlns="urn:jbpm.org:jpdl-3.2" name="Complex">
<description>
Complex description
</description>
<start-state name="start-state1">
<transition to="task-node1"></transition>
</start-state>
<task-node name="task-node3">
<task name="Task3_1">
<assignment actor-id="1"></assignment>
</task>
<transition to="end-state1"></transition>
</task-node>
<node name="node1">
<transition to="task-node3"></transition>
</node>
<join name="join1">
<transition to="node1"></transition>
</join>
<fork name="fork1">
<transition to="task-node2"></transition>
<transition to="node2" name="to node2"></transition>
<transition to="state1" name="to state1"></transition>
</fork>
<task-node name="task-node2">
<task name="Task2_1">
<assignment actor-id="1"></assignment>
</task>
<task name="Task2_2">
<assignment actor-id="1"></assignment>
</task>
<transition to="join1"></transition>
</task-node>
<task-node name="task-node1">
<task name="Task1_1">
<assignment actor-id="1"></assignment>
</task>
<transition to="fork1"></transition>
</task-node>
<node name="node2">
<transition to="end-state2"></transition>
</node>
<state name="state1">
<transition to="end-state2"></transition>
</state>
<end-state name="end-state1"></end-state>
<end-state name="end-state2"></end-state>
</process-definition>
Try to do this:
- create a process instance and start it
- a Task1_1 instance is created: end it
- the root token halts at the fork and three children tokens are created
1) the first causes the creation of a Task2_1 instance and of a Task2_2 instance
2) the second halts at the state1 state
3) the third dies at the end-state2 state
Now, there are two cases:
CASE A)
- signal the second token: it then goes on and dies at end-state2 state
- end Task2_1 and Task2_2 instances so that the first token goes on and reaches the join
- now, the root token is restored and goes through node1 and task-node3 nodes, causing the creation of a Task3_1 instance
This is what I would expect!
CASE B)
- end Task2_1 and Task2_2 instances so that the first token goes on and reaches the join
- signal the second token: it then goes on and dies at end-state2 state
- now, the root token is ended, halting the process instance!
This is not the expected behaviour, as I would expect that the root token is restored because now all the sibling tokens of those that have reached the join node are ended, so the parent token (= the root token) should be restored and should continue to node1 and subsequent nodes.
Moreover, I would not expect that the behaviour is different depending on the ordering of the actions "signal the state1 token" and "signal the task-node2 token".
My suspect is this: in case B) the join node is not "triggered" anymore after Task2_1 and Task2_2 are ended, so it can't restore the parent node. Moreover, when the second children token is signalled, it reaches end-state2: jBPM then realizes that all of the sibling tokens are also ended, so it wrongly decides that the parent token should also be ended.
--
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
16 years, 9 months
[JBoss JIRA] Created: (JBPM-2297) Fork activities don't save child executions
by Alexis Seigneurin (JIRA)
Fork activities don't save child executions
-------------------------------------------
Key: JBPM-2297
URL: https://jira.jboss.org/jira/browse/JBPM-2297
Project: JBoss jBPM
Issue Type: Bug
Security Level: Public (Everyone can see)
Components: Runtime Engine
Affects Versions: jBPM 4.0.0.Beta2
Reporter: Alexis Seigneurin
When you create a fork activity, child executions are not saved in the session. The consequence is that, at some point, an execution with ID 0 is searched in the database:
Exception in thread "main" org.hibernate.ObjectNotFoundException: No row with the given identifier exists: [org.jbpm.jpdl.internal.model.JpdlExecution#0]
at org.hibernate.impl.SessionFactoryImpl$1.handleEntityNotFound(SessionFactoryImpl.java:375)
at org.hibernate.proxy.AbstractLazyInitializer.checkTargetState(AbstractLazyInitializer.java:79)
at org.hibernate.proxy.AbstractLazyInitializer.initialize(AbstractLazyInitializer.java:68)
at org.hibernate.proxy.AbstractLazyInitializer.getImplementation(AbstractLazyInitializer.java:111)
at org.hibernate.proxy.pojo.cglib.CGLIBLazyInitializer.invoke(CGLIBLazyInitializer.java:140)
at org.jbpm.jpdl.internal.model.JpdlExecution$$EnhancerByCGLIB$$9a4d98d.createTask(<generated>)
at org.jbpm.jpdl.internal.activity.TaskActivity.execute(TaskActivity.java:49)
at org.jbpm.pvm.internal.model.op.ExecuteActivity.perform(ExecuteActivity.java:57)
at org.jbpm.pvm.internal.model.ExecutionImpl.performAtomicOperationSync(ExecutionImpl.java:589)
at org.jbpm.pvm.internal.model.ExecutionImpl.performAtomicOperation(ExecutionImpl.java:562)
at org.jbpm.pvm.internal.model.ExecutionImpl.take(ExecutionImpl.java:444)
at org.jbpm.pvm.internal.model.ExecutionImpl.take(ExecutionImpl.java:448)
at org.jbpm.jpdl.internal.activity.ForkActivity.execute(ForkActivity.java:61)
at org.jbpm.pvm.internal.model.op.ExecuteActivity.perform(ExecuteActivity.java:57)
at org.jbpm.pvm.internal.model.ExecutionImpl.performAtomicOperationSync(ExecutionImpl.java:589)
at org.jbpm.pvm.internal.model.ExecutionImpl.performAtomicOperation(ExecutionImpl.java:562)
at org.jbpm.pvm.internal.model.ExecutionImpl.start(ExecutionImpl.java:201)
at org.jbpm.pvm.internal.cmd.StartProcessInstanceInLatestCmd.execute(StartProcessInstanceInLatestCmd.java:63)
at org.jbpm.pvm.internal.cmd.StartProcessInstanceInLatestCmd.execute(StartProcessInstanceInLatestCmd.java:39)
at org.jbpm.pvm.internal.svc.DefaultCommandService.execute(DefaultCommandService.java:42)
at org.jbpm.pvm.internal.tx.StandardTransactionInterceptor.execute(StandardTransactionInterceptor.java:54)
at org.jbpm.pvm.internal.svc.EnvironmentInterceptor.execute(EnvironmentInterceptor.java:54)
at org.jbpm.pvm.internal.svc.RetryInterceptor.execute(RetryInterceptor.java:55)
at org.jbpm.pvm.internal.svc.ExecutionServiceImpl.startProcessInstanceByKey(ExecutionServiceImpl.java:72)
To fix the issue, in the ForkActivity class, the childExecution instances which are created must be saved. I attached a patch (though I guess there is another way to perform the save by using commands).
--
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
16 years, 9 months
[JBoss JIRA] Created: (JBPM-2116) Index names too long for DB2 8.2
by Jiri Pechanec (JIRA)
Index names too long for DB2 8.2
--------------------------------
Key: JBPM-2116
URL: https://jira.jboss.org/jira/browse/JBPM-2116
Project: JBoss jBPM
Issue Type: Bug
Security Level: Public (Everyone can see)
Components: Core Engine
Affects Versions: jBPM-3.2.5.SP3
Environment: DB2 8.2, JDBC driver 2.10.52, RHEL4
Reporter: Jiri Pechanec
Two indices are not created beacuse their names are too long
2009-03-19 06:13:23,025 ERROR [org.hibernate.tool.hbm2ddl.SchemaExport] Unsuccessful: create index IDX_PSTATE_SBPRCDEF on JBPM_NODE (SUBPROCESSDEFINITION_)
2009-03-19 06:13:23,025 ERROR [org.hibernate.tool.hbm2ddl.SchemaExport] DB2 SQL error: SQLCODE: -107, SQLSTATE: 42622, SQLERRMC: IDX_PSTATE_SBPRCDEF;18
2009-03-19 06:13:23,362 ERROR [org.hibernate.tool.hbm2ddl.SchemaExport] Unsuccessful: create index IDX_VARINST_TKVARMP on JBPM_VARIABLEINSTANCE (TOKENVARIABLEMAP_)
2009-03-19 06:13:23,362 ERROR [org.hibernate.tool.hbm2ddl.SchemaExport] DB2 SQL error: SQLCODE: -107, SQLSTATE: 42622, SQLERRMC: IDX_VARINST_TKVARMP;18
--
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
16 years, 9 months