Note: This bug is displayed in read-only format because the product is no longer active in Red Hat Bugzilla.

Bug 1057113

Summary: Aborting process instance with human task impossible
Product: [Retired] JBoss BPMS Platform 6 Reporter: Zuzana Krejčová <zkrejcov>
Component: Business CentralAssignee: Maciej Swiderski <mswiders>
Status: CLOSED WONTFIX QA Contact: Zuzana Krejčová <zkrejcov>
Severity: urgent Docs Contact:
Priority: high    
Version: unspecifiedCC: kverlaen, lpetrovi
Target Milestone: ---Keywords: Regression, TestBlocker
Target Release: ---   
Hardware: Unspecified   
OS: Unspecified   
Whiteboard:
Fixed In Version: Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2014-01-23 16:50:28 UTC Type: Bug
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:
Attachments:
Description Flags
server log none

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 1 Zuzana Krejčová 2014-01-23 13:25:39 UTC 
Created attachment 854380 [details]
server log
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.