Page tree
Skip to end of metadata
Go to start of metadata

Draft for ?

This concept provides ideas to implement "long running actions" in the context of Magnolia 5's new UI.

This concept is very drafty, and is currently busy with trying to differentiate different types of long running actions.


There are a bunch of actions in Magnolia that can't be executed synchronously - because they take too long, or simply because users don't need to wait for them to complete. Users might need to be informed of the progress, and/or of completion, but this isn't always a must. In some case, we could implement them synchronously (search, stats, ...) but prefer to give the user an immediate (intermediate) response.

Use cases

  • File upload. already implemented. Events exist and uses push. Could actually provide a basic impl for non-queued LRAs
  • Activation
  • Search results
  • Statistics and other calculated numbers...
    • eg. forum statistics (number of messages, most active users, ...) can be long to calculate. They should probably be cached for a certain amount of time, and/or generate on demand. So a good example would be such a screen, where, if they haven't been calculated yet, the user gets a screen without the actual figures and an indication that this is being calculated. Once calculated, the display refreshes with the current info. If we use a caching mechanism, we display the "last calculation time" and allow the user to refresh.
  • Re-indexing
  • Image processing
  • In fact, any user action could be (should be?) considered an LRA, because we have absolutely no guarantee of response time. Client network could break (I'm in a tunnel!), server could go down or simply be overloaded.

Different types of Long Running Actions (LRAs)

  • Triggered by a user action, and need to provide feedback to the user (progress and completion). The user can not do anything else until the action completes. (this is probably never ideal, but it looks like this is our current case - except we don't actually "block" the ui, but responses to actions are "queued" up?)
  • Triggered by a user action, and need to provide feedback to the user (progress and completion). The user typically does not do anything else until the action completes. (but can)
  • Triggered by a user action, but the user typically goes about other activities while the process runs in the background (re-indexing, activating, ...)
  • Triggered by the system or other non-user actions (workflow, ...). Progress and completion for these can be relevant to (some) users, but this will typically not involved an on-screen notification or progress bar (Andreas?). Completion can be broadcasted via Pulse, however.


The below are currently mostly questions

  • Queuing mechanism
    • LRAs should be queued to avoid overloading the system
    • Failling LRAs could go in an error queue
    • Super long LRAs could timeout and go to the error queue, or to a specific timed-out queue
    • Admins need a way to look at the queue
      • Number of items in queue, name/title
      • Remove items from queue
      • Re-do items in error/timeout queue
    • Simple ad-hoc queue, or full-blown buzzword-full mechanism with persistence, transactions et tutti quanti ?
  • For more "urgent" actions, perhaps a global queue doesn't work. If there are many users, it'd be unfair to have a simple LRA's user wait for longer LRAs to finish first.
    • Multiple queues with some form balancing ?
    • Weigh different kinds of jobs ?
    • User queues vs system queues ?
  • Perhaps just skip the queuing mechanism altogether for user-actions. But then:
    • We need a mechanism to cancel/stop running actions (and ask confirmation from user ?)
      • If an LRA was running and the user clicks somewhere else, especially if that was going to trigger another LRA, ask if they confirm ?
      • If not, then we do need a queue per-user, else we're potentially clogging the system with LRAs that'll run in parallel and forever for a single user
  • Always timeout LRAs, whether in a queue or not
    • Should timeout be given by the LRA itself ? (Time me out if I take longer than X)
  • Use PUSH for results/progress. Retrofit pulse to use push too.



  • No labels


  1. There should be also a solution where i can send a message to the user which starts an action, even if he is unlogged. Or it would be nice if there is a solution to configure a onComplete action after this long term actions.

  2. I've done research and designs for dealing with long-running actions in Apps and Pulse. Mockups exist, but none of this has been documented in the UX wiki space as of yet. Please contact me when you work on this topic and keep me in the loop.


    1. Actually I linked to some UX pages in the References section above. Feel free to update with more up-to-date or relevant links (smile)

  3. It's Oct 2015... any updates on this?