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

 

Next steps

  • Jan will proceed with impl of workaround for command based actions using scheduler.
  • No labels

8 Comments

  1. Richard Unger

    See Issue DEAD-7 for a live example of this...

    1. Jan Haderka

      Thx, linked Marvin's ticket to the one mentioned above.

  2. 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.

    1. Jan Haderka

      Asynchronous action API/implementation:

      • This concept is not about solution to long running actions. For that we have completely separate concept that will be implemented in its own time (depending on Vaadin 7.2). 
      • This is a workaround to prevent long running actions from blocking UI until we can have asynchronous actions.
      • Read more about this at Client Behavior - Long running Tasks using Activation.

      Use of scheduler:

      • Offloads action from UI to separate thread and allows UI to return immediately.
      • Doesn't introduce yet another thread pool that would need to be managed and removed once the permanent solution is in place.
      • Is already capable of working with commands and passing context to them.

      1. 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.

        1. 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

  3. Marvin Kerkhoff

    Is there any example of the implementation? I don't get it run on the Deadlink App

  4. Lars Fischer

    See http://documentation.magnolia-cms.com/display/DOCS/Action+definition and the

    asynchronous / delay / parallel

    parameters.