[JBoss JIRA] Created: (JBPM-2919) Memory leak because of org.jbpm.JbpmConfiguration.jbpmConfigurationStacks not released
by Mauro Molinari (JIRA)
Memory leak because of org.jbpm.JbpmConfiguration.jbpmConfigurationStacks not released
--------------------------------------------------------------------------------------
Key: JBPM-2919
URL: https://jira.jboss.org/browse/JBPM-2919
Project: jBPM
Issue Type: Bug
Security Level: Public (Everyone can see)
Components: Runtime Engine
Affects Versions: jBPM 3.2.7
Reporter: Mauro Molinari
When class org.jbpm.JbpmConfiguration gets initialized by the class loader, a static variable named jbpmConfigurationStacks gets initialized. This is a ThreadLocal, and so it gets registered in the java.lang.Thread.threadLocals map of the calling thread.
However, if jBPM is embedded into a web application, this means that that variable is registered on one of the HTTP threads of the application server. When the web application shuts down, the mapping is not removed, because there's no code in jBPM that takes care of this task.
Fortunately, the value of this thread local is of type ArrayList, which is a class which is surely loaded by the root class loader, so no references to the webapp class loader are retained. However, Tomcat 6.0.28 still says the following:
SEVERE: The web application [/webappname] created a ThreadLocal with key of type [org.jbpm.JbpmConfiguration.StackThreadLocal] (value [org.jbpm.JbpmConfiguration$StackThreadLocal@26fe26cc]) and a value of type [java.util.ArrayList] (value [[]]) but failed to remove it when the web application was stopped. This is very likely to create a memory leak.
A fix could be to do a remove() on that ThreadLocal when a call to org.jbpm.JbpmConfiguration.popJbpmConfiguration() causes the list to become empty.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
13 years, 4 months
[JBoss JIRA] Created: (JBPM-2133) Error handling in CommandServiceBean.execute
by Volker Börchers (JIRA)
Error handling in CommandServiceBean.execute
--------------------------------------------
Key: JBPM-2133
URL: https://jira.jboss.org/jira/browse/JBPM-2133
Project: JBoss jBPM
Issue Type: Patch
Security Level: Public (Everyone can see)
Affects Versions: jBPM 3.2.6.SP1
Environment: irrelevant
Reporter: Volker Börchers
Priority: Minor
regards CommndServiceBean.execute(Command command):
public Object execute(Command command)
{
JbpmContext jbpmContext = jbpmConfiguration.createJbpmContext();
try
{
log.debug("executing " + command);
return command.execute(jbpmContext);
}
catch (RuntimeException e)
{
sessionContext.setRollbackOnly();
throw e;
}
catch (Exception e)
{
sessionContext.setRollbackOnly();
throw new JbpmException("failed to execute " + command, e);
}
finally
{
jbpmContext.close();
}
}
If an exception occurres in Command.excute() it's important that this exception is propagated to the client to allow for proper exception handling to differentiate e.g. between a concurrency issue ("job is locked by...") and a database error.
These exceptions are not propagated to the client if the jbpmContext.close() in the finally block throws an exceptions. This might very well happen since it performs non-trivial operations, e.g. access the database. (Actually it it seems to me as if the failure of jbpmContext.close() always happen, maybe since after the setRollbackOnly() no new connections are possible.)
The following change will fix the problem:
public Object execute(Command command)
{
JbpmContext jbpmContext = jbpmConfiguration.createJbpmContext();
boolean exceptionThrown = false;
try
{
log.debug("executing " + command);
return command.execute(jbpmContext);
}
catch (RuntimeException e)
{
sessionContext.setRollbackOnly();
exceptionThrown = true;
throw e;
}
catch (Exception e)
{
sessionContext.setRollbackOnly();
exceptionThrown = true;
throw new JbpmException("failed to execute " + command, e);
}
finally
{
try
{
jbpmContext.close();
}
catch (Exception e2) {
if (exceptionThrown)
{
// JIRA XX: do not hide thrown exception
log.error("exception on context close", e2);
}
else
{
throw e2;
}
}
}
}
--
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
13 years, 4 months
[JBoss JIRA] Created: (JBPM-2142) No save of processInstance in TaskInstanceEndCommand
by Joram Barrez (JIRA)
No save of processInstance in TaskInstanceEndCommand
-----------------------------------------------------
Key: JBPM-2142
URL: https://jira.jboss.org/jira/browse/JBPM-2142
Project: JBoss jBPM
Issue Type: Bug
Security Level: Public (Everyone can see)
Components: Core Engine
Affects Versions: jBPM 3.3.1 GA, jBPM 3.2.7 GA
Reporter: Joram Barrez
Priority: Minor
The TaskInstanceEndCommand does not save the processInstance.
This means (among others) that the process logs will not be persisted to the database, since they are only stored upon a call to the save() method on the jBPM Context.
The solution is simple, add
jbpmContext.save(taskInstance.getProcessInstance());
to the command.
I haven't checked the other commands, but the bug can occur in other 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
13 years, 4 months
[JBoss JIRA] Created: (JBPM-2031) Some bidirectional associations do not use inverse="true"
by Tomasz Wysocki (JIRA)
Some bidirectional associations do not use inverse="true"
---------------------------------------------------------
Key: JBPM-2031
URL: https://jira.jboss.org/jira/browse/JBPM-2031
Project: JBoss jBPM
Issue Type: Feature Request
Security Level: Public (Everyone can see)
Components: Core Engine
Affects Versions: jBPM 3.3.1 GA
Environment: Tested with MySQL with query log enabled in JUnit.
Reporter: Tomasz Wysocki
Priority: Minor
Currently couple of bidirectional associations do not use inverse="true" on one-to-many side (collection)
The examples are
- ProcessInstance.instances
- CompositeLog.children
I'm sure there are more of them.
Lack of inverse="true" results in additional "UPDATE" statement being issued by hibernate to create a relationship from a one-to-many side.
This is not necessary when java code is updating both ends of an association.
Some use-cases where lots of new processes are being created would see a performance improvement.
CompositeLog logging overhead will decrease (only INSERT will be issued - no UPDATE)
Please consider reviewing all of your bidirectional associations with respect to this optimization.
--
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
13 years, 4 months
[JBoss JIRA] Created: (JBPM-1463) task condition element is not exist jpdl3.2.3 schema, but in code
by xiong cf (JIRA)
task condition element is not exist jpdl3.2.3 schema, but in code
-----------------------------------------------------------------
Key: JBPM-1463
URL: https://jira.jboss.org/jira/browse/JBPM-1463
Project: JBoss jBPM
Issue Type: Bug
Security Level: Public (Everyone can see)
Components: jPDL 3
Affects Versions: jPDL 3.2.3
Reporter: xiong cf
in jpdl-3.2.xsd :
<xs:element name="task">
<xs:complexType>
<xs:choice minOccurs="0" maxOccurs="unbounded">
<xs:element ref="description" />
<xs:element ref="assignment"/>
<xs:element ref="controller"/>
<xs:element ref="event"/>
<xs:element ref="timer"/>
<xs:element name="reminder">
<xs:complexType>
<xs:attribute name="duedate" type="xs:string" use="required" />
<xs:attribute name="repeat" type="xs:string" />
</xs:complexType>
</xs:element>
</xs:choice>
<xs:attribute name="name" type="xs:string" />
<xs:attribute name="blocking" type="booleanType" default="false"/>
<xs:attribute name="signalling" type="booleanType" default="true"/>
<xs:attribute name="description" type="xs:string" />
<xs:attribute name="duedate" type="xs:string" />
<xs:attribute name="swimlane" type="xs:string" />
<xs:attribute name="priority" type="priorityType" default="normal" />
<xs:attribute name="notify" type="booleanType" default="false"/>
</xs:complexType>
</xs:element>
is not exist element condition.
but in org.jbpm.jpdl.xml.JpdlXmlReader line312 has:
// get the condition
String condition = taskElement.elementTextTrim("condition");
if (condition!=null) {
task.setCondition(condition);
} else {
task.setCondition(taskElement.attributeValue("condition"));
}
and in org.jbpm.graph.node.TaskNode line161 has:
if ( (createTasks)
&& (tasks!=null) ) {
Iterator iter = tasks.iterator();
while (iter.hasNext()) {
Task task = (Task) iter.next();
executionContext.setTask(task);
if (evaluateTaskCondition(task.getCondition(), executionContext)) {
tmi.createTaskInstance(task, executionContext);
}
}
}
I think in jbpm3.2.3 should be spport task condition element , but document and schema not new
--
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
13 years, 4 months
[JBoss JIRA] Created: (JBPM-2128) integrity constraint (********.FK_PROCIN_ROOTTKN) violated - parent key not found
by Jasphior S (JIRA)
integrity constraint (********.FK_PROCIN_ROOTTKN) violated - parent key not found
----------------------------------------------------------------------------------
Key: JBPM-2128
URL: https://jira.jboss.org/jira/browse/JBPM-2128
Project: JBoss jBPM
Issue Type: Bug
Security Level: Public (Everyone can see)
Components: Core Engine
Environment: Windows XP, Std Desktop
jBOSS 4.2.2, ORACLE 10, JBoss jBPM3 - Core 3.3.0.GA, EJB3
Reporter: Jasphior S
I face the below exceptions while trying to create a ProcessInstance.....
root cause : javax.ejb.EJBException: org.hibernate.exception.ConstraintViolationException: Could not execute JDBC batch update
and the other root cause:
java.sql.BatchUpdateException: ORA-02291: integrity constraint (******.FK_PROCIN_ROOTTKN) violated - parent key not found
However, the most annoying part is this occurs inconsistently.
After encountering this problem and after restarting the jboss server the error is gone! Again after a while starts occurring...
I'm not sure about the root cause, but I think the TransactionManager/related configuration has something to do with this...(because this never occurred when I wasn't using any TransactionManager...)
I'm using the below configuration for TransactionManagement in persistence.xml
<property name="hibernate.transaction.factory_class" value="org.hibernate.ejb.transaction.JoinableCMTTransactionFactory"></property>
<property name="hibernate.transaction.manager_lookup_class" value="org.hibernate.transaction.JBossTransactionManagerLookup"></property>
<property name="hibernate.current_session_context_class" value="org.hibernate.context.JTASessionContext"></property>
and below in the jbpm-cfg.xml
<jbpm-context>
<service name="persistence">
<factory>
<bean class="org.jbpm.persistence.db.DbPersistenceServiceFactory">
<field name="isTransactionEnabled">
<false />
</field>
<field name="isCurrentSessionEnabled">
<false />
</field>
</bean>
</factory>
</service>
</jbpm-context>
When I googled abt this problem, I found many with similar issues but, couldn't find a valid solution for this... hence, I'm logging here... If there is any solution/this is fixed(in new releases) pls mention the same.
--
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
13 years, 5 months
[JBoss JIRA] Created: (JBPM-2138) JBPM_LOG table column 'exception' is too small, throws RE: ORA-01461: can bind a LONG value only for insert into a LONG column
by George Mournos (JIRA)
JBPM_LOG table column 'exception' is too small, throws RE: ORA-01461: can bind a LONG value only for insert into a LONG column
------------------------------------------------------------------------------------------------------------------------------
Key: JBPM-2138
URL: https://jira.jboss.org/jira/browse/JBPM-2138
Project: JBoss jBPM
Issue Type: Bug
Security Level: Public (Everyone can see)
Environment: jbpm 3.2.6 on an oracle server, any application server or OS
Reporter: George Mournos
If an action throws an exception, the stack trace is logged in the JBPM_LOG table.
However, in case of a very long stack trace (longer than 4000 characters), this throws an oracle Exception.
"RE: ORA-01461: can bind a LONG value only for insert into a LONG column"
The bug is difficult to trace, since the exception is only thrown at hibernate session.flush() and not at the actual insert...
Actual exception stacktrace that presented the problem was the exception stacktrace of weblogic, 7200 chars. (the jbpm action was executing business logic running in its own transaction).
--
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
13 years, 5 months
[JBoss JIRA] Created: (JBPM-2139) Concurrency problems with the Join node despite lock="pessimistic"
by George Mournos (JIRA)
Concurrency problems with the Join node despite lock="pessimistic"
------------------------------------------------------------------
Key: JBPM-2139
URL: https://jira.jboss.org/jira/browse/JBPM-2139
Project: JBoss jBPM
Issue Type: Bug
Security Level: Public (Everyone can see)
Components: Core Engine
Environment: jbpm 3.2.6, weblogic 9.2.1, oracle 10g
Reporter: George Mournos
We are evaluating jbpm for concurrency.
We created a test case with a lot of concurrency.
The test process has:
* a fork
* 10 nodes with async="true" and
* a join with lock="pessimistic".
In some of the parallel nodes we get the exception:
Caused by: org.hibernate.StaleObjectStateException: Row was updated or deleted by another transaction (or unsaved-value mapping was incorrect): [org.jbpm.graph.exe.Token#121]
We checked that the lock mode is persisted correctly and that the join node actually does the lock.UPGRADE.
We attach the testcase, the test process definition, and the full stacktrace.
We enforced a stricter locking strategy, namely locking the process instance for as long as the command executor was working and the test worked ok.
However, we finally dropped this solution because it was creating a lot of row locks and could lead to transaction timeouts and finally chose another solution.
All of our business logic is in nodes with async="true" and goes through the jms executor.
We serialize consumption of jms messages belonging to the same process instance by using a JMS extention of Weblogic, called UnitOfOrder.
WLMessageProducer messageProducer = (WLMessageProducer)session.createProducer(destination);
messageProducer.setUnitOfOrder(processInstance + "");
This workaround could be useful to people working on weblogic.
--
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
13 years, 5 months