|Summary:||Aborting process instance with human task impossible|
|Product:||[Retired] JBoss BPMS Platform 6||Reporter:||Zuzana Krejčová <zkrejcov>|
|Component:||Business Central||Assignee:||Maciej Swiderski <mswiders>|
|Status:||CLOSED WONTFIX||QA Contact:||Zuzana Krejčová <zkrejcov>|
|Target Milestone:||---||Keywords:||Regression, TestBlocker|
|Fixed In Version:||Doc Type:||Bug Fix|
|Doc Text:||Story Points:||---|
|Last Closed:||2014-01-23 16:50:28 UTC||Type:||Bug|
|oVirt Team:||---||RHEL 7.3 requirements from Atomic Host:|
Description Zuzana Krejčová 2014-01-23 13:22:47 UTC
Description of problem: I'm using a simple process: Start -> User Task (assigned to 'user') -> End. If I try to abort an instance of this process, I get WARN [org.drools.persistence.SingleSessionCommandService] Could not commit session: com.arjuna.ats.jta.exceptions.RollbackException: ARJUNA016081: The transaction implementation threw a RollbackException ... The instance stays active, 'user' cannot see the task, instance cannot be aborted. After a few tries to abort the instance, no other process instance could be started - the start form (the default one, since I need no input from user) button doesn't react. Later, another WARN got added to the server log: WARN [com.arjuna.ats.arjuna] (Transaction Reaper) ARJUNA012117: TransactionReaper::check timeout for TX 0:ffff0a2203ec:29a33de7:52e110b9:350 in state RUN WARN [com.arjuna.ats.arjuna] (Transaction Reaper Worker 0) ARJUNA012095: Abort of action id 0:ffff0a2203ec:29a33de7:52e110b9:350 invoked while multiple threads active within it. WARN [com.arjuna.ats.arjuna] (Transaction Reaper Worker 0) ARJUNA012108: CheckedAction::check - atomic action 0:ffff0a2203ec:29a33de7:52e110b9:350 aborting with 1 threads active! WARN [org.hibernate.engine.transaction.synchronization.internal.SynchronizationCallbackCoordinatorImpl] (Transaction Reaper Worker 0) Transaction afterCompletion called by a background thread! Delaying action until the original thread can handle it. [status=4] WARN [org.hibernate.engine.transaction.synchronization.internal.SynchronizationCallbackCoordinatorImpl] (Transaction Reaper Worker 0) Transaction afterCompletion called by a background thread! Delaying action until the original thread can handle it. [status=4] WARN [com.arjuna.ats.arjuna] (Transaction Reaper Worker 0) ARJUNA012121: TransactionReaper::doCancellations worker Thread[Transaction Reaper Worker 0,5,main] successfully canceled TX 0:ffff0a2203ec:29a33de7:52e110b9:350 After that, I cannot see any process instances nor definitions and the deployment unit also disappeared. When I try to stop the server (^C) so I can do some clean-up safely, it hangs after INFO [org.jboss.as.server.deployment] (MSC service thread 1-4) JBAS015877: Stopped deployment business-central.war (runtime-name: business-central.war) in 314ms Fortunately, kill -9 works... Similar thing probably happened with ER7 as well, just not so dire - there were some intermittent problems with aborting process instances, unfortunately quite hard to reproduce. Version-Release number of selected component (if applicable): BPMS 6.0 CR1
Comment 2 Maciej Swiderski 2014-01-23 14:41:17 UTC
Zuzana, just tried that on two environments: - CR1 with enabled security policy - just it needs to be updated as mentioned in this bz - todays build (that will be actually CR2) without security policy In any of these cases I could not reproduce the issue, process can be aborted. Processes I tried: - HR example from jbpm-playground repository - (aborted just after process was created, or after task was completed where other tasks were in line) - created new process definition (based on your description - start -> user task -> end) and abort process instance just after it was created. Any other hints that would help to reproduce?
Comment 3 Zuzana Krejčová 2014-01-23 14:59:08 UTC
Some more information: - happened with PostgreSQL 9.1 - both with and without security policy - steps: start appserver with clean db and enabled example repo, create the above mentioned process in the 'org' package, build and deploy, start process instance, abort from the instance details panel that just appeared. I will post more info as I get it.
Comment 4 Zuzana Krejčová 2014-01-23 16:50:28 UTC
Turns out to be a configuration problem and a case for documentation. The root cause is that there is a user A and a group A. More clearly: user called A has a few groups, user B has a few groups, one of them is called A (the same as the other user). I opened a new documentation bug, so that this gets finally covered. Issues caused by this are rather surprising and quite unpleasant. Sorry for the false alarm.