[JBoss JIRA] Created: (JBPM-1139) The ClassUtil class is not thread-safe
by Wojciech Gdela (JIRA)
The ClassUtil class is not thread-safe
--------------------------------------
Key: JBPM-1139
URL: http://jira.jboss.com/jira/browse/JBPM-1139
Project: JBoss jBPM
Issue Type: Bug
Components: Core Engine
Affects Versions: jBPM jPDL 3.2.3
Reporter: Wojciech Gdela
Assigned To: Tom Baeyens
Attachments: ClassUtil-concurrency-issue.zip
The ClassUtil class is not thread-safe. The exception will occur when two thread simultanously try do deserialize variables from two different process definitions. Look at the code:
{code}
public ContextObjectInputStream(final InputStream in,
ProcessInstance processInstance) throws IOException {
super(in);
this.setProcessInstance(processInstance);
ClassUtil.setProcessInstance(processInstance);
}
...
protected Class resolveClass(final ObjectStreamClass desc)
throws IOException, ClassNotFoundException {
return ClassUtil.forName(desc.getName(), ContextObjectInputStream.class);
}
...
ContextObjectInputStream cois = new ContextObjectInputStream(bais, definition.createProcessInstance());
// when here another thread tries to execute the same code with another process instance there will be a problem
return cois.readObject();
{/code}
Further description of issue is in attached test case.
--
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
14 years, 7 months
[JBoss JIRA] Created: (JBPM-1178) Script conditions in transitions are evaluated as expressions by the decision node
by Romain Lamarche (JIRA)
Script conditions in transitions are evaluated as expressions by the decision node
----------------------------------------------------------------------------------
Key: JBPM-1178
URL: http://jira.jboss.com/jira/browse/JBPM-1178
Project: JBoss jBPM
Issue Type: Bug
Components: Core Engine
Affects Versions: jBPM jPDL 3.2.2
Environment: Windows XP, JBoss AS 4.2.2GA, MS SQL EXPRESS 2005, Jdk5
Reporter: Romain Lamarche
Assigned To: Tom Baeyens
The decision node does not evaluate scripts in conditional transitions.
Indeed, the execute method of node type decision does not check what type of condition it is.
Listing of the wrong code :
(file Decision.java lines 120-135 in Jbpm Jpdl 3.2.2)
} else {
// new mode based on conditions in the transition itself
Iterator iter = leavingTransitions.iterator();
while (iter.hasNext() && (transition==null)) {
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;
}
}
}
}
The problem is the "JbpmExpressionEvaluator".
--
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
14 years, 11 months
[JBoss JIRA] Created: (JBPM-1288) evaluate the previous methods
by Tom Baeyens (JIRA)
evaluate the previous methods
-----------------------------
Key: JBPM-1288
URL: http://jira.jboss.com/jira/browse/JBPM-1288
Project: JBoss jBPM
Issue Type: Task
Security Level: Public (Everyone can see)
Components: PVM
Reporter: Tom Baeyens
this relates to
Execution.getPreviousNode()
Execution.getPreviousTransition()
Node.isPreviousNeeded()
Comment in Execution.java:
// TODO evaluate the previous methods
// these methods are kind of performance optimisations. a sequence and
// some other specific control flow implementations can be optimised if they
// have access to the previous node or transition.
// Those activities could also be implemented by letting the activities store
// the contextual information in process variables or some other execution
// context. But with the previous properties as done now, these control flow
// nodes can be implemented without storing an extra record. It's only a property
// that is only updated when the node configuration indicates that it's needed.
// (see also Node.isPreviousNeeded())
--
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, 6 months
[JBoss JIRA] Created: (JBPM-1113) Maximum number of cursors exceeded: ResultSet not closed?
by Martin Vecera (JIRA)
Maximum number of cursors exceeded: ResultSet not closed?
---------------------------------------------------------
Key: JBPM-1113
URL: http://jira.jboss.com/jira/browse/JBPM-1113
Project: JBoss jBPM
Issue Type: Bug
Components: Core Engine
Affects Versions: jBPM jPDL 3.2.2
Environment: SOA-P 4.2.0.beta2 (JBossESB 4.2.1), Oracle 10g
Reporter: Martin Vecera
Assigned To: Tom Baeyens
We deployed a performance test (see attached file) based on bpm_orchestration2.
When we generated a large backlog of messages (10,000) there started to be problems with cursors. This doesn't happen when BPM is not used. See attached file for server log.
11:59:10,560 WARN [JDBCSupport] SQLException caught, SQLState 72000 code:1000- assuming deadlock detected, try:23
java.sql.SQLException: ORA-01000: maximum open cursors exceeded
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:743)
at oracle.jdbc.driver.T4CPreparedStatement.doOall8(T4CPreparedStatement.java:216)
at oracle.jdbc.driver.T4CPreparedStatement.executeForRows(T4CPreparedStatement.java:955)
at oracle.jdbc.driver.OracleStatement.doExecuteWithTimeout(OracleStatement.java:1168)
at oracle.jdbc.driver.OraclePreparedStatement.executeInternal(OraclePreparedStatement.java:3316)
at oracle.jdbc.driver.OraclePreparedStatement.executeUpdate(OraclePreparedStatement.java:3400)
at org.jboss.resource.adapter.jdbc.WrappedPreparedStatement.executeUpdate(WrappedPreparedStatement.java:251)
at org.jboss.messaging.core.impl.JDBCPersistenceManager$1HandleBeforeCommit1PCRunner.doTransaction(JDBCPersistenceManager.java:1593)
at org.jboss.messaging.core.impl.JDBCSupport$JDBCTxRunner2.execute(JDBCSupport.java:465)
at org.jboss.messaging.core.impl.JDBCSupport$JDBCTxRunner2.executeWithRetry(JDBCSupport.java:503)
at org.jboss.messaging.core.impl.JDBCPersistenceManager.handleBeforeCommit1PC(JDBCPersistenceManager.java:1680)
at org.jboss.messaging.core.impl.JDBCPersistenceManager$TransactionCallback.beforeCommit(JDBCPersistenceManager.java:2790)
at org.jboss.messaging.core.impl.tx.Transaction.commit(Transaction.java:208)
at org.jboss.jms.server.endpoint.ServerConnectionEndpoint.sendTransaction(ServerConnectionEndpoint.java:474)
at org.jboss.jms.server.endpoint.advised.ConnectionAdvised.org$jboss$jms$server$endpoint$advised$ConnectionAdvised$sendTransaction$aop(ConnectionAdvised.java:101)
at org.jboss.jms.server.endpoint.advised.ConnectionAdvised$sendTransaction_N3268650789275322226.invokeNext(ConnectionAdvised$sendTransaction_N3268650789275322226.java)
at org.jboss.jms.server.container.SecurityAspect.handleSendTransaction(SecurityAspect.java:195)
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:585)
at org.jboss.aop.advice.PerInstanceAdvice.invoke(PerInstanceAdvice.java:121)
at org.jboss.jms.server.endpoint.advised.ConnectionAdvised$sendTransaction_N3268650789275322226.invokeNext(ConnectionAdvised$sendTransaction_N3268650789275322226.java)
at org.jboss.jms.server.container.ServerLogInterceptor.invoke(ServerLogInterceptor.java:105)
at org.jboss.jms.server.endpoint.advised.ConnectionAdvised$sendTransaction_N3268650789275322226.invokeNext(ConnectionAdvised$sendTransaction_N3268650789275322226.java)
at org.jboss.jms.server.endpoint.advised.ConnectionAdvised.sendTransaction(ConnectionAdvised.java)
at org.jboss.jms.wireformat.ConnectionSendTransactionRequest.serverInvoke(ConnectionSendTransactionRequest.java:82)
at org.jboss.jms.server.remoting.JMSServerInvocationHandler.invoke(JMSServerInvocationHandler.java:143)
at org.jboss.remoting.ServerInvoker.invoke(ServerInvoker.java:795)
at org.jboss.remoting.transport.socket.ServerThread.processInvocation(ServerThread.java:573)
at org.jboss.remoting.transport.socket.ServerThread.dorun(ServerThread.java:387)
at org.jboss.remoting.transport.socket.ServerThread.run(ServerThread.java:166)
--
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, 6 months