Bug 1270872 - EWS,WLS: Locks are not released when user logs out
Summary: EWS,WLS: Locks are not released when user logs out
Keywords:
Status: CLOSED EOL
Alias: None
Product: JBoss BRMS Platform 6
Classification: Retired
Component: Business Central
Version: 6.2.0
Hardware: Unspecified
OS: Unspecified
high
medium
Target Milestone: ER5
: 6.2.0
Assignee: manstis
QA Contact: Jiri Locker
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2015-10-12 14:56 UTC by Zuzana Krejčová
Modified: 2020-03-27 19:45 UTC (History)
3 users (show)

Fixed In Version:
Clone Of:
Environment:
Last Closed: 2020-03-27 19:45:23 UTC
Type: Bug
Embargoed:


Attachments (Terms of Use)

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.


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