Abstract
We have long running actions concept, however due to scheduling issues, this concept is not implemented yet and will not be for while. In the mean time there are long running actions that currently block UI and unfortunately have potential to block whole server hence the intermediate solution is required.
Execution of actions
Problem
- UI actions (any, but specially those invoking commands) are waiting for completion of the action before returning control to user.
- Invoking any such action temporarily blocks user. However invoking multiples of such actions, can cause whole server getting blocked or even crash.
- Details on how to reproduce the issue: Client Behavior - Long running Tasks using Activation
Investigation team
- Sasha
- Espen
- Jan
Investigation
- UI actions (any, but specially those invoking commands) are waiting for completion of the action before returning control to user.
- Investigation summarised in
MGNLUI-2783
-
Getting issue details...
STATUS
- didn't confirm possibility to bring down whole server
- issue exists for single user and is quite annoying to any user running into it
- Issue becomes more pronounced (client doesn't come back after long running action finishes) when having Apache in front on Tomcat
Intermediate solution
- Just for commands based actions
- Use scheduler to invoke passed in commands w/ passed in parameters
- make asynchronous invocation optional (configurable via action definition)
- if enabled, show temp message to user saying that action was scheduled and is being executed in the background
Long term solution
- Implements Concept Long Running Actions
Next steps
- Jan will proceed with impl of workaround for command based actions using scheduler.
Overview
Content Tools
Apps
Activity
8 Comments
Richard Unger
See Issue DEAD-7 for a live example of this...
Jan Haderka
Thx, linked Marvin's ticket to the one mentioned above.
Richard Unger
I don't really see the advantage of using the scheduler for this.
All that seems necessary is to delegate the operation to its own thread. The scheduler isn't required. And using the scheduler doesn't get around the problem that once the action executes in its own thread, it can't directly interact with the UI any more. Asynchronous actions (whether called by scheduler or otherwise) therefore need to be very careful about which parts of the magnolia APIs they use. They can't use anything that directly talks to Vaadin.
Jan Haderka
Asynchronous action API/implementation:
Use of scheduler:
Richard Unger
Ok, I think I misunderstood - so the idea is to use the existing thread-pool and other infrastructure from the scheduler to help implement the workaround. I couldn't see the need for scheduling immediatly executing tasks, but I see now that wasn't the plan anyway. Sorry.
Jan Haderka
No problem. That's why we write those pages to make everything clear.
I really appreciate that you took time to read it and write back about your concerns.
Cheers,
Jan
Marvin Kerkhoff
Is there any example of the implementation? I don't get it run on the Deadlink App
Lars Fischer
See http://documentation.magnolia-cms.com/display/DOCS/Action+definition and the
asynchronous / delay / parallel
parameters.