[JBoss JIRA] Created: (JBPM-2797) Bug in LockMonitor unlocks EVERY Job, not only overdue ones
by Bernd Ruecker (JIRA)
Bug in LockMonitor unlocks EVERY Job, not only overdue ones
-----------------------------------------------------------
Key: JBPM-2797
URL: https://jira.jboss.org/jira/browse/JBPM-2797
Project: jBPM
Issue Type: Bug
Security Level: Public (Everyone can see)
Components: Runtime Engine
Affects Versions: jBPM 3.2.8
Reporter: Bernd Ruecker
Assignee: Bernd Ruecker
The LockMonitorThread has a really huge bug.
It queries all jobs with overdue lock time:
Date threshold = new Date(System.currentTimeMillis() - maxLockTime - lockBufferTime);
List overdueJobs = jbpmContext.getJobSession().findJobsWithOverdueLockTime(threshold);
by this query:
<query name="JobSession.findJobsWithOverdueLockTime">
select job
from org.jbpm.job.Job as job
where job.lockTime > :threshold
</query>
This finds all jobs with a lock timer NEWER than the treshold, not OLDER as it should be. So the query must be:
<query name="JobSession.findJobsWithOverdueLockTime">
select job
from org.jbpm.job.Job as job
where job.lockTime < :threshold
</query>
So if a job runs exactly at the time the LockMonitorThread comes active, this leads to a StaleObjectException in the JobExecution. Since the LockMonitorThread runs only every minute, this is a pretty rare case. The more puzzling it was to find ;-) Surprising, that it wasn't recognized that long!
I commit the changed query to HEAD.
--
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
14 years
[JBoss JIRA] Created: (JBPM-2823) Lazy loading of ExceptionHandler causes Exception in JTA Env
by Robert Schmelzer (JIRA)
Lazy loading of ExceptionHandler causes Exception in JTA Env
------------------------------------------------------------
Key: JBPM-2823
URL: https://jira.jboss.org/jira/browse/JBPM-2823
Project: jBPM
Issue Type: Bug
Security Level: Public (Everyone can see)
Affects Versions: jBPM 3.2.8
Reporter: Robert Schmelzer
The fix for https://jira.jboss.org/jira/browse/JBPM-1775 does not work in JTA environment with JtaDbPersistenceService and following config:
jbpm-context>
<service name="persistence">
<factory>
<bean class="org.jbpm.persistence.jta.JtaDbPersistenceServiceFactory">
<field name="isCurrentSessionEnabled"><true /></field>
<field name="isTransactionEnabled"><false /></field>
</bean>
</factory>
</service>
<service name="tx" factory="org.jbpm.tx.TxServiceFactory"/>
<service name="message" factory="at.telekom.wfm.process.queue.JbpmJmsMessageServiceFactory" />
<service name="scheduler" factory="org.jbpm.scheduler.db.DbSchedulerServiceFactory" />
<service name="authentication" factory="org.jbpm.security.authentication.DefaultAuthenticationServiceFactory" />
</jbpm-context>
--
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
14 years
[JBoss JIRA] Created: (JBPM-2824) New implementation of equals and hashcode for ProcessInstance breaks behaviour
by Robert Schmelzer (JIRA)
New implementation of equals and hashcode for ProcessInstance breaks behaviour
------------------------------------------------------------------------------
Key: JBPM-2824
URL: https://jira.jboss.org/jira/browse/JBPM-2824
Project: jBPM
Issue Type: Bug
Security Level: Public (Everyone can see)
Affects Versions: jBPM 3.2.8
Reporter: Robert Schmelzer
The equals implementation of ProcessInstance now contains key, if the id is not set. The equals implementation of Token also includes equals for ProcessInstance. This means that setting the key properties from within a running process changes the hashcode of the Token and therefore the Process variables will not be found anymore as long as the id of the ProcessInstance is not found.
Furthermore it should be discussed how it affects performance to include ProcessInstance and Processdefinition in every call of equals and hashcode for a Token.
--
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
14 years
[JBoss JIRA] Created: (JBPM-2943) Problem terminating concurent executions that have active sub-processes [jBPM 4.3/4.4 + Oracle]
by Michal Klimuk (JIRA)
Problem terminating concurent executions that have active sub-processes [jBPM 4.3/4.4 + Oracle]
-----------------------------------------------------------------------------------------------
Key: JBPM-2943
URL: https://jira.jboss.org/browse/JBPM-2943
Project: jBPM
Issue Type: Bug
Security Level: Public (Everyone can see)
Components: Runtime Engine
Affects Versions: jBPM 4.4, jBPM 4.3
Environment: JDK 1.6_20, Oracle 10, Spring 2.5.6, Hibernate 3.3.1.GA
Reporter: Michal Klimuk
I have a process that contains a fork activity with two branches - one containing a sub-process and the other any type of node from which we can terminate the whole process directly. A simplified version for test purposes would be:
{code:xml}
<?xml version="1.0" encoding="UTF-8"?>
<process name="p1"
schemaLocation="http://jbpm.org/4.0/jpdl http://docs.jboss.org/jbpm/xsd/jpdl-4.0.xsd"
xmlns="http://jbpm.org/4.0/jpdl">
<start g="143,27,80,40" name="start">
<transition g="-54,-22" name="to fork1" to="fork1" />
</start>
<fork g="143,117,48,48" name="fork1">
<transition g="-38,-22" name="to p2" to="p2" />
<transition g="34,-14" name="to state1" to="state1" />
</fork>
<state g="199,214,108,52" name="state1">
<transition to="join1" />
<transition g="-11,-21" name="end" to="end2" />
</state>
<sub-process g="18,227,92,52" name="p2" sub-process-key="p2">
<transition to="join1" />
</sub-process>
<join g="141,334,48,48" name="join1">
<transition to="end" />
</join>
<end-cancel g="405,217,92,102" name="end2" />
<end g="141,446,80,40" name="end" />
</process>
{code}
When I run the process and try to signal node 'state1' to end the whole process I get a constraint violation :
{color:red}
org.hibernate.exception.ConstraintViolationException: could not delete: [org.jbpm.pvm.internal.model.ExecutionImpl#10003]
at org.hibernate.exception.SQLStateConverter.convert(SQLStateConverter.java:94)
at org.hibernate.exception.JDBCExceptionHelper.convert(JDBCExceptionHelper.java:66)
at org.hibernate.persister.entity.AbstractEntityPersister.delete(AbstractEntityPersister.java:2569)
at org.hibernate.persister.entity.AbstractEntityPersister.delete(AbstractEntityPersister.java:2725)
at org.hibernate.action.EntityDeleteAction.execute(EntityDeleteAction.java:97)
at org.hibernate.engine.ActionQueue.execute(ActionQueue.java:279)
at org.hibernate.engine.ActionQueue.executeActions(ActionQueue.java:263)
at org.hibernate.engine.ActionQueue.executeActions(ActionQueue.java:172)
at org.hibernate.event.def.AbstractFlushingEventListener.performExecutions(AbstractFlushingEventListener.java:321)
at org.hibernate.event.def.DefaultAutoFlushEventListener.onAutoFlush(DefaultAutoFlushEventListener.java:64)
at org.hibernate.impl.SessionImpl.autoFlushIfRequired(SessionImpl.java:996)
at org.hibernate.impl.SessionImpl.list(SessionImpl.java:1141)
at org.hibernate.impl.QueryImpl.list(QueryImpl.java:102)
at org.hibernate.impl.AbstractQueryImpl.uniqueResult(AbstractQueryImpl.java:835)
at org.jbpm.pvm.internal.hibernate.DbSessionImpl.findProcessInstanceByIdIgnoreSuspended(DbSessionImpl.java:211)
at org.jbpm.pvm.internal.hibernate.DbSessionImpl.deleteProcessInstance(DbSessionImpl.java:251)
at org.jbpm.pvm.internal.model.ExecutionImpl.end(ExecutionImpl.java:382)
at org.jbpm.jpdl.internal.activity.EndActivity.execute(EndActivity.java:82)
at org.jbpm.jpdl.internal.activity.EndActivity.execute(EndActivity.java:45)
at org.jbpm.pvm.internal.model.op.ExecuteActivity.perform(ExecuteActivity.java:60)
at org.jbpm.pvm.internal.model.ExecutionImpl.performAtomicOperationSync(ExecutionImpl.java:656)
at org.jbpm.pvm.internal.model.ExecutionImpl.performAtomicOperation(ExecutionImpl.java:616)
at org.jbpm.pvm.internal.model.ExecutionImpl.signal(ExecutionImpl.java:417)
at org.jbpm.pvm.internal.cmd.SignalCmd.execute(SignalCmd.java:61)
at org.jbpm.pvm.internal.cmd.SignalCmd.execute(SignalCmd.java:35)
at org.jbpm.pvm.internal.svc.DefaultCommandService.execute(DefaultCommandService.java:42)
at org.jbpm.pvm.internal.tx.SpringCommandCallback.doInTransaction(SpringCommandCallback.java:45)
at org.springframework.transaction.support.TransactionTemplate.execute(TransactionTemplate.java:128)
at org.jbpm.pvm.internal.tx.SpringTransactionInterceptor.execute(SpringTransactionInterceptor.java:55)
at org.jbpm.pvm.internal.svc.EnvironmentInterceptor.executeInNewEnvironment(EnvironmentInterceptor.java:53)
at org.jbpm.pvm.internal.svc.EnvironmentInterceptor.execute(EnvironmentInterceptor.java:40)
at org.jbpm.pvm.internal.svc.RetryInterceptor.execute(RetryInterceptor.java:55)
at org.jbpm.pvm.internal.svc.ExecutionServiceImpl.signalExecutionById(ExecutionServiceImpl.java:88)
at org.jbpm.test.SubprocessTest.testEndWithActiveSubprocesses(SubprocessTest.java:25)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
at java.lang.reflect.Method.invoke(Method.java:597)
at org.springframework.test.context.junit4.SpringTestMethod.invoke(SpringTestMethod.java:160)
at org.springframework.test.context.junit4.SpringMethodRoadie.runTestMethod(SpringMethodRoadie.java:233)
at org.springframework.test.context.junit4.SpringMethodRoadie$RunBeforesThenTestThenAfters.run(SpringMethodRoadie.java:333)
at org.springframework.test.context.junit4.SpringMethodRoadie.runWithRepetitions(SpringMethodRoadie.java:217)
at org.springframework.test.context.junit4.SpringMethodRoadie.runTest(SpringMethodRoadie.java:197)
at org.springframework.test.context.junit4.SpringMethodRoadie.run(SpringMethodRoadie.java:143)
at org.springframework.test.context.junit4.SpringJUnit4ClassRunner.invokeTestMethod(SpringJUnit4ClassRunner.java:160)
at org.junit.internal.runners.JUnit4ClassRunner.runMethods(JUnit4ClassRunner.java:51)
at org.junit.internal.runners.JUnit4ClassRunner$1.run(JUnit4ClassRunner.java:44)
at org.junit.internal.runners.ClassRoadie.runUnprotected(ClassRoadie.java:27)
at org.junit.internal.runners.ClassRoadie.runProtected(ClassRoadie.java:37)
at org.junit.internal.runners.JUnit4ClassRunner.run(JUnit4ClassRunner.java:42)
at org.springframework.test.context.junit4.SpringJUnit4ClassRunner.run(SpringJUnit4ClassRunner.java:97)
at org.eclipse.jdt.internal.junit4.runner.JUnit4TestReference.run(JUnit4TestReference.java:49)
at org.eclipse.jdt.internal.junit.runner.TestExecution.run(TestExecution.java:38)
at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.runTests(RemoteTestRunner.java:467)
at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.runTests(RemoteTestRunner.java:683)
at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.run(RemoteTestRunner.java:390)
at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.main(RemoteTestRunner.java:197)
Caused by: java.sql.SQLException: ORA-02292: violation de contrainte (BDOOA.FK_EXEC_SUPEREXEC) d'intégrité - enregistrement fils existant
at oracle.jdbc.driver.DatabaseError.throwSqlException(DatabaseError.java:112)
at oracle.jdbc.driver.T4CTTIoer.processError(T4CTTIoer.java:331)
at oracle.jdbc.driver.T4CTTIoer.processError(T4CTTIoer.java:288)
at oracle.jdbc.driver.T4C8Oall.receive(T4C8Oall.java:745)
at oracle.jdbc.driver.T4CPreparedStatement.doOall8(T4CPreparedStatement.java:216)
at oracle.jdbc.driver.T4CPreparedStatement.executeForRows(T4CPreparedStatement.java:966)
at oracle.jdbc.driver.OracleStatement.doExecuteWithTimeout(OracleStatement.java:1170)
at oracle.jdbc.driver.OraclePreparedStatement.executeInternal(OraclePreparedStatement.java:3339)
at oracle.jdbc.driver.OraclePreparedStatement.executeUpdate(OraclePreparedStatement.java:3423)
at org.hibernate.persister.entity.AbstractEntityPersister.delete(AbstractEntityPersister.java:2551)
... 54 more
{color}
I investigated the problem and I found out that it is due to the fact that we never try to terminate an existing sub-process from within the ExecutionImpl.end() method. It causes a delete of the parent execution row although it is still referenced by SUPEREXEC_ column of the sub-process.
I created a patch that works and that consists on adding the following code to ExecutionImpl.end(String state) (my code in the middle paragraph):
{code}
// end all child executions
// making a copy of the executions to prevent ConcurrentMoidificationException
List<ExecutionImpl> executionsToEnd = new ArrayList<ExecutionImpl>(executions);
for (ExecutionImpl child: executionsToEnd) {
child.end(state);
}
// terminates the sub-process if it exists
if(subProcessInstance != null) {
// to avoid the return signal (see superProcessExecution.signal() in the end(String state) method)
subProcessInstance.setSuperProcessExecution(null);
subProcessInstance.end(state);
}
setState(state);
{code}
I don't know if it is the right approach but it works pretty much fine. I join both the patch and the test module.
--
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
14 years
[JBoss JIRA] Created: (JBPM-2942) springprocessengine does not use the sessionfactory name supplied in the cfg.xml file to get the LocalSessionFactoryBean
by Renaud Bruyeron (JIRA)
springprocessengine does not use the sessionfactory name supplied in the cfg.xml file to get the LocalSessionFactoryBean
------------------------------------------------------------------------------------------------------------------------
Key: JBPM-2942
URL: https://jira.jboss.org/browse/JBPM-2942
Project: jBPM
Issue Type: Bug
Security Level: Public (Everyone can see)
Components: Runtime Engine
Affects Versions: jBPM 4.4
Environment: all
Reporter: Renaud Bruyeron
It is possible to specify the factory name to be used by JBPM when using the spring integration via springhelper.
This is done via:
{code:title=jbpm.tx.spring.cfg.xml}
<transaction-context>
<transaction type="spring" />
<hibernate-session current="true" factory="sessionFactory"/>
</transaction-context>
{code}
However when the processengine is constructed, this name is not used, and a type search in the application context is done instead:
{code:title=SpringProcessEngine.java}
if (configuration.isInstantiatedFromSpring()) {
applicationContext = (ApplicationContext) configuration.getApplicationContext();
springProcessEngine = new SpringProcessEngine();
springProcessEngine.applicationContext = applicationContext;
springProcessEngine.initializeProcessEngine(configuration);
LocalSessionFactoryBean localSessionFactoryBean = springProcessEngine.get(LocalSessionFactoryBean.class); // WRONG...
//...
}
{code}
This code above is only used during init to run db checks I think. However when multiple session factories are available, this code may end up using the wrong LSFB:
{code}
Multiple beans for type class org.springframework.orm.hibernate3.LocalSessionFactoryBean found. Returning the first result.
{code}
SpringProcessEngine should used the name in the XML, or (less desirable) use a spring-supplied name (via springhelper property?).
--
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
14 years