History | Log In     View a printable version of the current page.  
We are currently focused especially on Moodle 2.0, Moodle 1.9.x bugs and Moodle 1.9.x testing.    Confused? Lost? Please read this introduction to the Tracker.
Issue Details (XML | Word | Printable)

Key: MDL-16002
Type: Bug Bug
Status: Resolved Resolved
Resolution: Fixed
Priority: Critical Critical
Assignee: Petr Škoda
Reporter: Petr Škoda
Votes: 0
Watchers: 2
Operations

If you were logged in you would be able to see more operations.
Moodle

rewrite upgrade locking

Created: 12/Aug/08 03:54 PM   Updated: 18/Aug/08 06:26 AM
Component/s: Administration
Affects Version/s: 1.9
Fix Version/s: 2.0

File Attachments: 1. Text File upgrade_locking_10.patch (49 kb)
2. Text File upgrade_locking_11.patch (48 kb)
3. Text File upgrade_locking_9.patch (49 kb)


Participants: Dan Poltawski, Eloy Lafuente (stronk7) and Petr Škoda
Security Level: None


 Description  « Hide
At present the upgrade lock is defined in active session, this is not enough because people often close browser is the upgrade takes too long which causes a lot of problems. ALso the site should not be accessible during the upgrade.

Solution is to store the upgrade flag in config table instead.

 All   Comments   Change History   Version Control      Sort Order: Ascending order - Click to sort in descending order
Petr Škoda - 12/Aug/08 05:31 PM
please review, I would like to get this into cvs asap

Dan Poltawski - 13/Aug/08 04:36 PM
I haven't had a chance to review the patch, but I read some chat about a locking technique used which is incompatible with NFS.

Please tread carefully with this as lots of sites with course data based on NFS!

Eloy Lafuente (stronk7) - 14/Aug/08 06:11 AM
Ah, this isn't using any filesystem locking, Dan. It's 100% DB semaphore. Just that.

I guess you hear about that when talking about new File API, and how we "lock" some files when iterating over them to be finally deleted. In that case, one flock() is used. And it really has problems under NFS.

Ciao :-)

Eloy Lafuente (stronk7) - 15/Aug/08 07:19 AM
Some comments about the execution I've performed:

- Big site with 150 courses and 1GB of moodledata.
- Course files and blog files migrated ok, showing progress bars perfectly. I tried second browser and got "upgrade is running" message.

- Got some strange feedback in assignment progress bar: "Migrated assignment submissions - 1820/1."
- Later in the assignment upgrade, I got a lot of: Error: could not insert new context level "70", instance "XXX" and it ended with one exception: Unknown exception related to local files (Invalid contextid)

- Immediately I opened another browser and it allowed me to run the modules upgrade. I guess the end of the script, deletes the semaphore properly, so this is correct.

So, initial tests look ok (although I haven't been able to end the process due to errors when upgrading assignments). Going to upgrade one small site now.

Ciao :-)

Eloy Lafuente (stronk7) - 15/Aug/08 07:24 AM
Upgrading small site the upgrade ended ok. Only one notice was showed in some of the upgrade pages like:

- messaging plugins.
- quiz reports
- portfolio type

The notice said:

Inccorect use of upgrade_log_start(), upgrade already logging.

    * line 893 of lib/adminlib.php: call to debugging()
    * line 320 of lib/adminlib.php: call to upgrade_log_start()
    * line 422 of admin/index.php: call to upgrade_plugins()

That's all. Ciao :-)

Petr Škoda - 18/Aug/08 06:26 AM
committed into cvs, thanks
please reopen in case of any problems or file new issue