[MGNLUI-2783] User is blocked in his browser session after starting long running Action Created: 31/Mar/14  Updated: 06/Aug/15  Resolved: 15/Apr/14

Status: Closed
Project: Magnolia UI
Component/s: None
Affects Version/s: 5.2
Fix Version/s: 5.2.4

Type: Bug Priority: Blocker
Reporter: Jan Haderka Assignee: Eric Hechinger
Resolution: Fixed Votes: 1
Labels: support
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Issue Links:
causality
is causing MGNLUI-2855 Ansynchonous action (activation) shou... Closed
dependency
depends upon MGNLWORKFLOW-222 Hardcoded values in WorkflowFormDialo... Closed
depends upon MGNLEE-358 Re-Add module scheduler to ee_bundle Closed
is depended upon by DEAD-7 Deadlink module causes weird vaadin e... Open
is depended upon by MGNLUI-1901 Asynchron Actions Closed
relation
is related to MGNLDAM-441 (Potentially) long running actions sh... Closed
is related to MGNLUI-2840 (Potentially) long running actions sh... Closed
is related to MGNLWORKFLOW-242 Enable workflow to run activation asy... Closed
Template:
Acceptance criteria:
Empty
Task DoD:
[ ]* Doc/release notes changes? Comment present?
[ ]* Downstream builds green?
[ ]* Solution information and context easily available?
[ ]* Tests
[ ]* FixVersion filled and not yet released
[ ]  Architecture Decision Record (ADR)
Bug DoR:
[ ]* Steps to reproduce, expected, and actual results filled
[ ]* Affected version filled
Release notes required:
Yes
Date of First Response:

 Description   

After starting one or more long running actions, user becomes blocked in given browser session. Logout/Login doesn't help. Logging in as same user in different browser allows user to interact w/ server again. UI becomes "unlocked" and responsive again once the long running action is finished.

Problem is more pronounced with Firefox and Chrome then with Safari. Didn't test on IE.

While server became very "sluggish" at some point due to number of running actions, our tests didn't confirm ability to completely bring down the server at this point.

The issue was not reproducible at all in Magnolia 5.0 using older version of Vaadin, which suggests issue is related to some change (probably introduction of locks) in Vaadin 7.1.

More details discussed/described at http://wiki.magnolia-cms.com/display/DEV/Concept+-+Long+running+actions+intermediate+solution



 Comments   
Comment by Jan Haderka [ 07/Apr/14 ]

Needs review and probably reopening. While the main issue is solved, i18n could be handled better and it probably deserves some integration tests ... pls beware that you need not only this change, but also changes in workflow branch to get everything working (tested on ui-5.3-snapshot & workflow-5.4-snapshot).

Comment by Christopher Zimmermann [ 08/Apr/14 ]

Commit: https://git.magnolia-cms.com/gitweb/?p=magnolia_ui.git;a=commitdiff;h=99805205ca7062361e9845f4a3e2fc6f40286714

Comment by Daniel Lipp [ 14/Apr/14 ]

I might not be not easy but we should cover the essential changes to AbstractCommandAction by unit tests.

Also I think this change should also be applied to master / 5.3, no?

Comment by Jan Haderka [ 14/Apr/14 ]

Yeah, port will be part of the merge.

Generated at Mon Feb 12 09:00:06 CET 2024 using Jira 9.4.2#940002-sha1:46d1a51de284217efdcb32434eab47a99af2938b.