Note: This is a beta release of Red Hat Bugzilla 5.0. The data contained within is a snapshot of the live data so any changes you make will not be reflected in the production Bugzilla. Also email is disabled so feel free to test any aspect of the site that you want. File any problems you find or give feedback here.
Bug 1057113 - Aborting process instance with human task impossible
Summary: Aborting process instance with human task impossible
Keywords:
Status: CLOSED WONTFIX
Alias: None
Product: JBoss BPMS Platform 6
Classification: Retired
Component: Business Central
Version: unspecified
Hardware: Unspecified
OS: Unspecified
high
urgent
Target Milestone: ---
: ---
Assignee: Maciej Swiderski
QA Contact: Zuzana Krejčová
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2014-01-23 13:22 UTC by Zuzana Krejčová
Modified: 2016-08-01 01:08 UTC (History)
2 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2014-01-23 16:50:28 UTC
Type: Bug


Attachments (Terms of Use)
server log (deleted)
2014-01-23 13:25 UTC, Zuzana Krejčová
no flags Details

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.


Note You need to log in before you can comment on or make changes to this bug.