Release Notes

Upon request - removed the word "-master" from zip title.

  • I liked the idea of this when you released it, but it's had little fanfare since.

    Just wanted to let you know that I've incorporated it into a project that has the potential for some long-running scripts and it seems great.  I haven't been able to test with any big data yet as it's still early but I'll let you know how it goes.

  • Hey Matt! I'm glad you were able to put it to good use. Please keep me updated. I'd be curious to see how you've incorporated it.

  • Well, here's the update - I've done some testing of this, and I'm completely in love with this plugin.

    For scripts that used to take forever, or I would create internal queues for and execute on cron, now can be done in more or less real time.

    I've recently used it for a plugin that handles batch relationships (think creating a relationship between you and the potentially unlimited number of people in a group when you join/leave), as well as some event based notification scripts.

    This is fast becoming one of my 'stock' plugins.

  • I have a question if someone that uses this plugin can maybe answer.

    Do we need to edit/add anything to this plugin to work for specific scripts or does it do that out of the box for at least Elgg default scripts?

    Thanks.

  • It won't do anything out of the box for Elgg default scripts - it's meant for developers to use as a dependency while building custom scripts.  To use it you need to offset your potentially long-running script to the 'shutdown', 'system' event while this plugin is active.

  • so is this essentially a way of creating 'background tasks' within elgg?
    e.g. if a page in elgg has a function for deleting a large amount of items, the function can be started and the page rendering completed in advance of the function completing?

    if so, how is that any better than launching the large delete function via some type of ajax or elgg_batch process?

    i am wondering if the related-items plugin might benefit from using vroom though presently i am not seeing how it could since it first runs a potentially lengthy process of accessing and preparing data and then renders the results to the browser.. the only way i could see this being improved via a shutdown tweak is if the whole page renders except for the function in related-items that is handled by vroom and then when that function is ready it renders to the page (last)..
    does that description fit with what vroom can do?
    thanks

  • how is that any better than launching the large delete function via some type of ajax or elgg_batch process?

    Sometimes you need your scripts to run on an event or plugin hook controlled by something that's not ajaxified.  Eg. Joining a group - this action currently takes a page refresh, and the resulting page isn't sent to the browser until Elgg has finished all of the scripts involved.

    I have a script that happens on the join event, so in that event I register a custom event handler for shutdown, and pass it the info it needs through elgg_set_config.  Then the browser can get the page before my long script runs.

    This can't do what you want for related-items though, it can't do pre-processing for page because the headers have already been sent to the browser - as far as the browser is concerned the connection is done.

  • Thanks Matt.

    I wish there were some real examples for the usage of the plugin to understand it better. Could it be used for any of the default plugins? or it is not necessary to use for any default plugins?

  • oh so.. what happens if the script fails..? e.g. the join doesn't complete for some reason.. would the rendered page contain a view that shows that the join completed?

  • No, the join happens before the page renders.  All data validation etc. can happen before shutdown.  This offsets scripts that the user doesn't need to wait around for - like sending notifications.

    Look at the code of this plugin to see what's actually happening, it's a very small plugin.

  • ah i see now, ok.. thanks for sharing

  • One issue I've identified - session variables don't seem to be set properly until a script has finished.  This means that when a script is still running when the next page reloads any messages set using system_message and register_error aren't getting through...

  • I have an issue when vroom is enabled, some pages turn blank (no error message). This happens in Chrome. Pages that have found to be empty: Some plugin settings pages and translation-editor search.

  • Any idea if Vroom is still useful in Elgg 1.9? I have no idea how to test it.

  • @darthvader - It is still useful. Try the latest version on github. (https://github.com/jumbojett/vroom)

  • This plugin definitely does work in 1.9 - this has become a staple in all of my projects now and is a dependency for many of my newer ones.

    @mjett - could you do me a favor and release the latest version here, mark it compatible with 1.8 and 1.9?

    I keep having to tell people to grab the latest from github when they ask me due to it being marked as a dependency :)

Stats

  • Category: Tools
  • License: GNU General Public License (GPL) version 2
  • Updated: 2014-11-17
  • Downloads: 1441
  • Recommendations: 12

Other Projects

View M. Jett's plugins