[JBoss JIRA] Created: (JBPM-1701) in WireContext: bug when elements inside a list are referenced from outside the list.
by Guillaume Porcher (JIRA)
in WireContext: bug when elements inside a list are referenced from outside the list.
-------------------------------------------------------------------------------------
Key: JBPM-1701
URL: https://jira.jboss.org/jira/browse/JBPM-1701
Project: JBoss jBPM
Issue Type: Bug
Security Level: Public (Everyone can see)
Components: PVM
Reporter: Guillaume Porcher
Priority: Critical
In this example:
public void testNamedElements() {
String contextText =
"<objects>" +
" <list name='l'>" +
" <object class='java.lang.Object' name='s'/>" +
" </list>" +
" <ref name='r' object='s' />" +
"</objects>";
WireContext wireContext = createWireContext(contextText);
assertNotNull(wireContext.get("s"));
assertNotNull(wireContext.get("l"));
assertNotNull(wireContext.get("r"));
assertSame(wireContext.get("s"), wireContext.get("r"));
wireContext = createWireContext(contextText);
assertNotNull(wireContext.get("r"));
assertNotNull(wireContext.get("l"));
assertNotNull(wireContext.get("s"));
assertSame(wireContext.get("s"), wireContext.get("r"));
}
the last assertion fails.
If the reference is accessed first, the object s is created when the reference is created, and then when the list is created.
If the list is created first, the reference uses the object in the list.
To fix this bug, I see 2 solutions:
- we can prevent the user from defining objects with names in lists.
- we can fix the creation of the list to check if some of the elements have already been created.
I think the first solution is better. If an element can be shared by more than one entity, it should be defined outside of all the entities and the entities should use ObjectReferences to access the shared element.
--
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
[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
[JBoss JIRA] Created: (JBPM-1685) Check persistence of exception field in JobImpl
by Guillaume Porcher (JIRA)
Check persistence of exception field in JobImpl
-----------------------------------------------
Key: JBPM-1685
URL: https://jira.jboss.org/jira/browse/JBPM-1685
Project: JBoss jBPM
Issue Type: Task
Security Level: Public (Everyone can see)
Components: PVM
Reporter: Guillaume Porcher
Priority: Critical
in jobs, there is a exception field to put the exception stacktrace
in hibernate mappings, this column length is set to 4000. Some stacktrace are more than 4000 char long, this creates an exception with hibernate.
<tomb> porcherg: the 4000 is because of some DB limitation
<tomb> i believe db2
<tomb> iirc, in db, the max string field is 4000
<tomb> if you want to go beyond that, we would need to use CLOBs
<tomb> but i'm open to alternatives
<tomb> maybe the stacktrace field should be a CLOB ?
<porcherg> tomb: the problem is that it creates an exception if it is too long
<tomb> yes
<tomb> so we have to fix it somehow
<tomb> just removing the 4000 limit is not good
<tomb> as it will not work on db2
<tomb> so we either manually truncate the exception field in the code
<tomb> in the setter
<tomb> or we change it into a clob
<tomb> probably the latter is better
<porcherg> maybe we can use hibernate "text" type
<porcherg> "text: Maps long Java strings to a SQL CLOB or TEXT type. "
<tomb> do you guys have access to db2 db ?
<tomb> the first thing we should do is verify if this problem is really present
<tomb> so we should remove the 4000 limit in the hibernate mappings and see if we can create that problem on db2
<tomb> once we can reproduce it, then we can start looking for alternatives that fix the problem on db2
<tomb> then we can see if the fix works on the other dbs
<tomb> i am a bit reluctant to start using clobs
<tomb> as this would be the first use case for it
<tomb> and clobs might lead to even more DB dependent issues...
<tomb> but if there is no other way, then we have to
<tomb> so let's start by removing the 4000 limit in the hibernate mappings and prioritizing that we have to test it in db2
--
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
[JBoss JIRA] Created: (JBPM-1438) Task assigned to different actor-id can be seen and manipulated in jBPM console
by Martin Vecera (JIRA)
Task assigned to different actor-id can be seen and manipulated in jBPM console
-------------------------------------------------------------------------------
Key: JBPM-1438
URL: https://jira.jboss.org/jira/browse/JBPM-1438
Project: JBoss jBPM
Issue Type: Bug
Security Level: Public (Everyone can see)
Components: Core Engine
Affects Versions: jPDL 3.2.2
Environment: JBossESB server 4.3.GA, bpm_orchestration4
Reporter: Martin Vecera
By default JBossESB server 4.3.GA has several jBPM users configured including 'user' and 'manager'.
bpm_orchestration4 example contains one process definition which assigns two tasks, first to actor-id 'user' and the second to actor-id 'manager'.
The problem is that the 'user' can see and manipulate both of the tasks.
Steps to reproduce:
1. download JBossESB server 4.3.GA
2. start it using bin/run.sh
3. go to samples/quickstarts/bpm_orchestration4
4. run one by one: ant deploy, ant deployProcess, ant startProcess
5. open jBPM console and login as 'user' with password 'user'
6. click on Tasks to see the task list and on Examine to open the task, then on Save and Close
7. refresh the task list and you can see second task assigned to 'manager', try to Examine it...
--
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
[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