Bug 1270872

Summary: EWS,WLS: Locks are not released when user logs out
Product: [Retired] JBoss BRMS Platform 6 Reporter: Zuzana Krejčová <zkrejcov>
Component: Business CentralAssignee: manstis
Status: CLOSED EOL QA Contact: Jiri Locker <jlocker>
Severity: medium Docs Contact:
Priority: high    
Version: 6.2.0CC: jlocker, kverlaen, lpetrovi
Target Milestone: ER5   
Target Release: 6.2.0   
Hardware: Unspecified   
OS: Unspecified   
Whiteboard:
Fixed In Version: Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2020-03-27 19:45:23 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:

Description Zuzana Krejčová 2015-10-12 14:56:34 UTC
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 11:19:43 UTC
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 14:17:42 UTC
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:

<listener>
  <listener-class>
    org.uberfire.backend.server.LockCleanupSessionListener
  </listener-class>
</listener>

Comment 3 Christian Sadilek 2015-10-13 22:27:07 UTC
PR sent: https://github.com/droolsjbpm/kie-wb-distributions/pull/118

Comment 7 Christian Sadilek 2015-10-14 22:14:02 UTC
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 13:51:27 UTC
Fixed on EWS 2 and 3.

Lock release upon log-out still not working on WLS.

Comment 9 Christian Sadilek 2015-11-10 19:33:13 UTC
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 19:37:13 UTC
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 14:33:15 UTC
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.