Uploaded image for project: 'Moodle'
  1. Moodle
  2. MDL-42040

Organize the registration of shutdown handlers

    Details

    • Type: Bug
    • Status: Closed
    • Priority: Critical
    • Resolution: Fixed
    • Affects Version/s: 2.6
    • Fix Version/s: 2.6
    • Component/s: General, Libraries
    • Labels:
    • Testing Instructions:
      Hide

      Note: all problem info goes the the error log because the page footer is already sent to output

      1/ test database sessions work (turn editing mode in course on and off)
      2/ verify profiling works (see description or ask Eloy how to set it up)
      3/ general install/upgrade/unittests

      Show
      Note: all problem info goes the the error log because the page footer is already sent to output 1/ test database sessions work (turn editing mode in course on and off) 2/ verify profiling works (see description or ask Eloy how to set it up) 3/ general install/upgrade/unittests
    • Affected Branches:
      MOODLE_26_STABLE
    • Fixed Branches:
      MOODLE_26_STABLE
    • Pull from Repository:
    • Pull Master Branch:
      w41_MDL-42040_m26_shutdown
    • Story Points (Obsolete):
      4
    • Sprint:
      BACKEND Sprint 5

      Description

      This issue arrived because, recently I've started to get some "$DB not available" messages when profiling pages, leading to the profiling runs not sent to DB. And I'm pretty sure that it has been working ok since 2.0, until we introduced the new sessions stuff that changed the internal order of those handlers.

      So please, avoid arguing things like "it should not be using $DB" and friends (I'm aware of them). It worked and now it does not. Let's try to improve the situation and the future.

      Right now the registration of shutdown handlers (register_shutdown_function) is completely chaotic and disorganized, and that can lead to more and more problems where some objects, not available anymore, or disposed by a previous handler are needed later in the chain of shutdowns.

      grep -lr register_shutdown_function *
      

      So we need some method to organize and force their registration in an ordered way, declaring their needs (DB, logging, whatever) and observing any dependencies between them and also, surely containing references to all the needed used to avoid its auto-disposal by php.

      Not sure how to encapsulate all that information (needs, dependencies, disposal) nor how to behave (multiple handlers vs a big one in charge of everything).

      But it should be computable, I hope. Ciao

        Gliffy Diagrams

          Attachments

            Activity

              People

              • Votes:
                0 Vote for this issue
                Watchers:
                4 Start watching this issue

                Dates

                • Created:
                  Updated:
                  Resolved:
                  Fix Release Date:
                  18/Nov/13