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

Cache definitions not being re-parsed during an upgrade.

    XMLWordPrintable

    Details

    • Type: Bug
    • Status: Closed
    • Priority: Blocker
    • Resolution: Fixed
    • Affects Version/s: 2.5
    • Fix Version/s: 2.5
    • Component/s: Caching
    • Labels:
    • Testing Instructions:
      Hide
      1. First download the attached test.php.
      2. Move the test.php script to your moodle directory.

      Test installation,

      1. Drop your database tables BUT leave your moodledata directory in tact
      2. Perform an install through your browser.
      3. Drop your database tables and delete your moodle data directory.
      4. Perform an install through your browser.
      5. Drop your database tables and delete your moodle data directory.
      6. Perform an install through CLI.

      Test upgrades

      1. Test upgrading 2.3 (browser)
        1. Install or restore a Moodle 2.3 site.
        2. Browse to test.php. Don't worry about what it says.
        3. Upgrade it to 2.5 through your browser.
        4. Browse the site and check that caches are being used (refresh a couple of times)
        5. Browse to test.php check that it says thats its setting the value.
        6. Refresh the page check that it says the value existed.
      2. Test upgrading 2.3 (cli)
        1. Install or restore a Moodle 2.3 site.
        2. Browse to test.php. Don't worry about what it says.
        3. Upgrade it to 2.5 through CLI.
        4. Browse the site and check that caches are being used (refresh a couple of times)
        5. Browse to test.php check that it says thats its setting the value.
        6. Refresh the page check that it says the value existed.
      3. Test upgrading 2.4 (browser)
        1. Install or restore a Moodle 2.4 site.
        2. Browse to test.php. Don't worry about what it says.
        3. Upgrade it to 2.5 through your browser.
        4. Browse the site and check that caches are being used (refresh a couple of times)
        5. Browse to test.php check that it says thats its setting the value.
        6. Refresh the page check that it says the value existed.
      4. Test upgrading 2.4 (cli)
        1. Install or restore a Moodle 2.4 site.
        2. Browse to test.php. Don't worry about what it says.
        3. Upgrade it to 2.5 through CLI.
        4. Browse the site and check that caches are being used (refresh a couple of times)
        5. Browse to test.php check that it says thats its setting the value.
        6. Refresh the page check that it says the value existed its setting the value.
      5. Test upgrading 2.4 with custom cache data (browser)
        1. Make a directory within your moodledata dir called "altcache" and make it writable by everyone (lazy approach there)
        2. Install or restore a Moodle 2.4 site.
        3. Browse to test.php. Don't worry about what it says.
        4. Log in as an admin
        5. Browse to Settings > Plugins > Caching > Configuration.
        6. Add a new file store instance and set it to use the altcache directory (give it the absolute path).
        7. Make application caches use the new file store instance by default.
        8. Upgrade it to 2.5 through your browser.
        9. Log in as an admin.
        10. Check that the altcache is being used for application caches still.
        11. Browse to test.php check that it says thats its setting the value.
        12. Refresh the page check that it says the value existed.
      6. Test upgrading 2.4 with custom cache data (cli)
        1. Delete everything within the altcache directory.
        2. Install or restore a Moodle 2.4 site.
        3. Browse to test.php. Don't worry about what it says.
        4. Log in as an admin
        5. Browse to Settings > Plugins > Caching > Configuration.
        6. Add a new file store instance and set it to use the altcache directory (give it the absolute path).
        7. Make application caches use the new file store instance by default.
        8. Upgrade it to 2.5 through cli
        9. Check that the altcache is being used for application caches still.
        10. Browse to test.php check that it says thats its setting the value.
        11. Refresh the page check that it says the value existed its setting the value.

      Test supporting systems that require install/upgrade.

      1. Install and initialise phpunit.
      2. Install and initialise behat.
      3. Increment the version number in version.php
      4. Test that PHPunit recognises it needs to be reinitialised.
      5. Test that Behat recognises it needs to be reinitialised.
      6. Re-initialise phpunit.
      7. Re-initialise behat.

      Test upgrade running concurrency.

      1. Delete everything in the altcache directory.
      2. Install or restore a Moodle 2.4 site. (It must have students + courses).
      3. Log in as an admin
      4. Browse to Settings > Plugins > Caching > Configuration.
      5. Add a new file store instance and set it to use the altcache directory (give it the absolute path).
      6. Make application caches use the new file store instance by default.
      7. Edit the mappings for the string cache and make it use the 'default application cache' (the original default).
      8. Start a second browser.
      9. In the second browser:
        • Browse to your site and log in as a student.
        • Browse to a course.
      10. In the first browser (logged in as an admin) start the upgrade.
      11. While the upgrade runs keep refreshing the course page in browser 2.
      12. In browser 1 progress through the installation right past saving the new settings.
      13. Check that browser 2 sees the upgrade running message during upgrade.
      14. Check that browser 2 sees the course page as soon as the upgrade is done.
      15. Ensure browser 1 doesn't see the upgrade running message at any point.

      Stress test CLI concurrency.

      1. Perform a fresh install of 2.3
      2. Switch to the master branch.
      3. Start upgrading the site through CLI.
      4. Open a browser and head to the site.
      5. Keep refreshing the page (very fast e.g. hold down ctrl + r).
      6. While the upgrade is running you should see the"upgrade running" notice.
      7. Keep an eye on your terminal.
      8. As soon as the upgrade finished stop refreshing.
      9. Check that the page loads and shows the front page. (no longer the upgrade running notice)
      Show
      First download the attached test.php. Move the test.php script to your moodle directory. Test installation, Drop your database tables BUT leave your moodledata directory in tact Perform an install through your browser. Drop your database tables and delete your moodle data directory. Perform an install through your browser. Drop your database tables and delete your moodle data directory. Perform an install through CLI. Test upgrades Test upgrading 2.3 (browser) Install or restore a Moodle 2.3 site. Browse to test.php. Don't worry about what it says. Upgrade it to 2.5 through your browser. Browse the site and check that caches are being used (refresh a couple of times) Browse to test.php check that it says thats its setting the value. Refresh the page check that it says the value existed. Test upgrading 2.3 (cli) Install or restore a Moodle 2.3 site. Browse to test.php. Don't worry about what it says. Upgrade it to 2.5 through CLI. Browse the site and check that caches are being used (refresh a couple of times) Browse to test.php check that it says thats its setting the value. Refresh the page check that it says the value existed. Test upgrading 2.4 (browser) Install or restore a Moodle 2.4 site. Browse to test.php. Don't worry about what it says. Upgrade it to 2.5 through your browser. Browse the site and check that caches are being used (refresh a couple of times) Browse to test.php check that it says thats its setting the value. Refresh the page check that it says the value existed. Test upgrading 2.4 (cli) Install or restore a Moodle 2.4 site. Browse to test.php. Don't worry about what it says. Upgrade it to 2.5 through CLI. Browse the site and check that caches are being used (refresh a couple of times) Browse to test.php check that it says thats its setting the value. Refresh the page check that it says the value existed its setting the value. Test upgrading 2.4 with custom cache data (browser) Make a directory within your moodledata dir called "altcache" and make it writable by everyone (lazy approach there) Install or restore a Moodle 2.4 site. Browse to test.php. Don't worry about what it says. Log in as an admin Browse to Settings > Plugins > Caching > Configuration. Add a new file store instance and set it to use the altcache directory (give it the absolute path). Make application caches use the new file store instance by default. Upgrade it to 2.5 through your browser. Log in as an admin. Check that the altcache is being used for application caches still. Browse to test.php check that it says thats its setting the value. Refresh the page check that it says the value existed. Test upgrading 2.4 with custom cache data (cli) Delete everything within the altcache directory. Install or restore a Moodle 2.4 site. Browse to test.php. Don't worry about what it says. Log in as an admin Browse to Settings > Plugins > Caching > Configuration. Add a new file store instance and set it to use the altcache directory (give it the absolute path). Make application caches use the new file store instance by default. Upgrade it to 2.5 through cli Check that the altcache is being used for application caches still. Browse to test.php check that it says thats its setting the value. Refresh the page check that it says the value existed its setting the value. Test supporting systems that require install/upgrade. Install and initialise phpunit. Install and initialise behat. Increment the version number in version.php Test that PHPunit recognises it needs to be reinitialised. Test that Behat recognises it needs to be reinitialised. Re-initialise phpunit. Re-initialise behat. Test upgrade running concurrency. Delete everything in the altcache directory. Install or restore a Moodle 2.4 site. (It must have students + courses). Log in as an admin Browse to Settings > Plugins > Caching > Configuration. Add a new file store instance and set it to use the altcache directory (give it the absolute path). Make application caches use the new file store instance by default. Edit the mappings for the string cache and make it use the 'default application cache' (the original default). Start a second browser. In the second browser: Browse to your site and log in as a student. Browse to a course. In the first browser (logged in as an admin) start the upgrade. While the upgrade runs keep refreshing the course page in browser 2. In browser 1 progress through the installation right past saving the new settings. Check that browser 2 sees the upgrade running message during upgrade. Check that browser 2 sees the course page as soon as the upgrade is done. Ensure browser 1 doesn't see the upgrade running message at any point. Stress test CLI concurrency. Perform a fresh install of 2.3 Switch to the master branch. Start upgrading the site through CLI. Open a browser and head to the site. Keep refreshing the page (very fast e.g. hold down ctrl + r). While the upgrade is running you should see the"upgrade running" notice. Keep an eye on your terminal. As soon as the upgrade finished stop refreshing. Check that the page loads and shows the front page. (no longer the upgrade running notice)
    • Workaround:
      Hide

      Always purge your cache immediately after upgrade.

      Show
      Always purge your cache immediately after upgrade.
    • Difficulty:
      Moderate
    • Affected Branches:
      MOODLE_25_STABLE
    • Fixed Branches:
      MOODLE_25_STABLE
    • Pull Master Branch:
      wip-MDL-39526-m25

      Description

      Presently cache definitions are not being re-parsed during uprgade.
      I believe I've tracked this back to caches being disabled completely during upgrade.

      I suspect/fear this may also mean that caches are not being purged after upgrade which is pretty concerning.
      Other problems may be lying hidden under the surface too.

        Attachments

          Issue Links

            Activity

              People

              • Assignee:
                samhemelryk Sam Hemelryk
                Reporter:
                samhemelryk Sam Hemelryk
                Peer reviewer:
                Eloy Lafuente (stronk7)
                Integrator:
                Damyon Wiese
                Tester:
                Jérôme Mouneyrac
                Participants:
                Component watchers:
                Matteo Scaramuccia, Amaia Anabitarte, Carlos Escobedo, Ferran Recio, Sara Arjona (@sarjona), Víctor Déniz Falcón
              • Votes:
                0 Vote for this issue
                Watchers:
                5 Start watching this issue

                Dates

                • Created:
                  Updated:
                  Resolved:
                  Fix Release Date:
                  14/May/13