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

Cache definitions not being re-parsed during an upgrade.

XMLWordPrintable

    • Icon: Bug Bug
    • Resolution: Fixed
    • Icon: Blocker Blocker
    • 2.5
    • 2.5
    • Caching
    • MOODLE_25_STABLE
    • MOODLE_25_STABLE
    • wip-MDL-39526-m25
    • Hide

      Always purge your cache immediately after upgrade.

      Show
      Always purge your cache immediately after upgrade.
    • Moderate
    • 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)

      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.

        1. concurrence - first errors (b).html
          71 kB
          Jérôme Mouneyrac
        2. concurrence - second errors - c.html
          17 kB
          Jérôme Mouneyrac
        3. Screenshot_10_05_13_2_29_PM.png
          310 kB
          Jérôme Mouneyrac
        4. Screenshot_10_05_13_2_37_PM.png
          228 kB
          Jérôme Mouneyrac
        5. test.php
          0.3 kB
          Sam Hemelryk

            samhemelryk Sam Hemelryk
            samhemelryk Sam Hemelryk
            Eloy Lafuente (stronk7) Eloy Lafuente (stronk7)
            Damyon Wiese Damyon Wiese
            Jérôme Mouneyrac Jérôme Mouneyrac
            Votes:
            0 Vote for this issue
            Watchers:
            5 Start watching this issue

              Created:
              Updated:
              Resolved:

                Error rendering 'clockify-timesheets-time-tracking-reports:timer-sidebar'. Please contact your Jira administrators.