Bug 1270872 - EWS,WLS: Locks are not released when user logs out
EWS,WLS: Locks are not released when user logs out
Product: JBoss BRMS Platform 6
Classification: JBoss
Component: Business Central (Show other bugs)
Unspecified Unspecified
high Severity medium
: ER5
: 6.2.0
Assigned To: manstis
Jiri Locker
Depends On:
  Show dependency treegraph
Reported: 2015-10-12 10:56 EDT by Zuzana Krejčová
Modified: 2018-01-29 21:26 EST (History)
3 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed:
Type: Bug
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)

  None (edit)
Description Zuzana Krejčová 2015-10-12 10:56:34 EDT
Description of problem:
On EWS (JWS) container (both 2.x and 3.x), an asset stays locked even after the user logs out of business-central.

Version-Release number of selected component (if applicable):
6.2 ER3

Steps to Reproduce:
1. Lock an asset - open a DRL, add a line.
2. Log out of business-central and log in again.
3. Navigate back to project authoring and the relevant project/package and asset.

Actual results:
The asset is still locked by you.

Expected results:
The asset is now unlocked.
Comment 1 Zuzana Krejčová 2015-10-13 07:19:43 EDT
Unfortunately, the same happens on Weblogic. It is reasonable to suspect the same problem on WAS, but I haven't had the chance to test that.
Comment 2 Christian Sadilek 2015-10-13 10:17:42 EDT
Lock cleanup on logout is triggered by an HTTP session listener. I was told we only need to focus on containers with Servlet 3 support or higher which don't require any additional information. It looks like we also need to support Servlet 2 containers?

In that case we need to add the following configuration to the web.xml files for these containers:

Comment 3 Christian Sadilek 2015-10-13 18:27:07 EDT
PR sent: https://github.com/droolsjbpm/kie-wb-distributions/pull/118
Comment 7 Christian Sadilek 2015-10-14 18:14:02 EDT
After deeper investigation, it turned out the issue is not that the session listener is not invoked, but that dependency injection (provided by CDI) within HttpSessionListeners (@WebListeners) is not supported in all required containers. Some versions of Tomcat7, E(J)WS and WLS do not support it. 

I’ve sent a new PR which changes our session listener to no longer rely on @Inject to get to its dependencies and retested to confirm: https://github.com/uberfire/uberfire/pull/191
Comment 8 Jiri Locker 2015-11-09 08:51:27 EST
Fixed on EWS 2 and 3.

Lock release upon log-out still not working on WLS.
Comment 9 Christian Sadilek 2015-11-10 14:33:13 EST
I've tested this again on WLS 12 (multiple versions) and it worked fine. 

However, I have a theory as to why you think it didn't work for you. Different containers have different implementations of their internal housekeeping and we're using an HttpSessionListener to release locks so we can have the same logic apply on both logout and sessions expiry. On WildFly, Tomcat, EWS we will see the listener being called and the locks released immediately after logout, while on WebLogic this takes a bit of time. Here's how you can test to confirm it's working:

- Open browser A
- Log in with User A 
- Start editing an asset (i.e. a DRL file) which will give you a lock

- Open and switch to (a different) browser B
- Log in with User B
- You will see the asset being locked (by User A) in the project explorer (grey lock symbol)

- Switch back to browser A
- Logout User A without saving

- Switch back to browser B
- Watch the project explorer: Within *2 minutes* or less you should see the lock symbol disappear as the container invalidates User A's session and releases the lock.
Comment 10 Christian Sadilek 2015-11-10 14:37:13 EST
I should add that a slight delay of lock releases after logout is by itself not an issue.
Comment 11 Jiri Locker 2015-11-11 09:33:15 EST
Christian, thanks for your prompt explanation. Your theory is correct, I wasn't aware of the delay that is specific for WebLogic. I'll update the test to take this into account.

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