concurrency failure with multisite when NOT network activated; advanced-cache.php data loss #59

Open
opened 2016-08-11 15:22:16 +01:00 by diablodale · 2 comments
diablodale commented 2016-08-11 15:22:16 +01:00 (Migrated from github.com)

While fixing https://github.com/petermolnar/wp-ffpc/issues/56, I discovered that wp-ffpc does not handle concurrency when read/writing the advanced-cache.php file under Wordpress multisite when not network activated.

Scenario:

  1. Have WP multisite
  2. Install wp-ffpc in the network. Do not network activate and, instead, enable it for subsite admins.
  3. The admin for subsite "alpha" activates wp-ffpc
  4. The admin for subsite "beta" activates wp-ffpc
  5. The admins for alpha and beta simultaneously change and save their wp-ffpc settings.

Step 5 exposes the problem. Two admins on two (or more) subsites could make changes to their wp-ffpc config at the same time. When different threads/processes are running the PHP, it is possible for the memory structure of the wpffpc global config to not match the memory structure of the on-disk advanced-cache.php due to the order of execution of the different site's threads. For example:

Thread alpha reads advanced-cache.php into memory
Thread beta reads advanced-cache.php into memory
Thread alpha makes changes to its copy in memory
Thread beta makes changes to its copy in memory
Thread alpha writes from memory to advanced-cache.php
Thread beta writes from memory to advanced-cache.php

Result:  advanced-cache.php has only beta changes. The alpha changes were lost.
This causes confusion by the site admins + support burden on the super admin.
  • One solution to a problem like this is to use a mutex or another type of exclusive locking mechanism. However, this can be complex to prevent excessive server load, long page times, or deadlock situations. http://anirudhsasikumar.net/blog/2008.01.15.html
  • Another solution is to avoid the scenario from occurring. For example, to only allow network activation in WP multisite (no activation/deactivation per-site).

I would recommend the second solution. That is, to only allow network activation and not per-site. In that solution, there is only one admin (the super admin) making changes. It is highly unlikely that super admin will have two browsers open at the same time, on the wpffpc settings page, pressing save at the same time.

While fixing https://github.com/petermolnar/wp-ffpc/issues/56, I discovered that wp-ffpc does not handle concurrency when read/writing the advanced-cache.php file under Wordpress multisite when _not_ network activated. Scenario: 1. Have WP multisite 2. Install wp-ffpc in the network. Do not network activate and, instead, enable it for subsite admins. 3. The admin for subsite "alpha" activates wp-ffpc 4. The admin for subsite "beta" activates wp-ffpc 5. The admins for alpha and beta simultaneously change and save their wp-ffpc settings. Step 5 exposes the problem. Two admins on two (or more) subsites could make changes to their wp-ffpc config at the same time. When different threads/processes are running the PHP, it is possible for the memory structure of the wpffpc global config to not match the memory structure of the on-disk advanced-cache.php due to the order of execution of the different site's threads. For example: ``` Thread alpha reads advanced-cache.php into memory Thread beta reads advanced-cache.php into memory Thread alpha makes changes to its copy in memory Thread beta makes changes to its copy in memory Thread alpha writes from memory to advanced-cache.php Thread beta writes from memory to advanced-cache.php Result: advanced-cache.php has only beta changes. The alpha changes were lost. This causes confusion by the site admins + support burden on the super admin. ``` - One solution to a problem like this is to use a mutex or another type of exclusive locking mechanism. However, this can be complex to prevent excessive server load, long page times, or deadlock situations. http://anirudhsasikumar.net/blog/2008.01.15.html - Another solution is to avoid the scenario from occurring. For example, to only allow network activation in WP multisite (no activation/deactivation per-site). I would recommend the second solution. That is, to only allow network activation and not per-site. In that solution, there is only one admin (the super admin) making changes. It is highly unlikely that super admin will have two browsers open at the same time, on the wpffpc settings page, pressing save at the same time.
petermolnar commented 2016-08-11 15:36:05 +01:00 (Migrated from github.com)

@diablodale sorry for being this quiet; the truth is, a long needed refactoring this plugin had been postponed by my for years now, and I still don't have the capacity to do it.

I welcome any changes, significant ones as well and I'd be happy to give access rights to the plugin's WordPress repository as well.

Would you be open for that?

@diablodale sorry for being this quiet; the truth is, a long needed refactoring this plugin had been postponed by my for years now, and I still don't have the capacity to do it. I welcome any changes, significant ones as well and I'd be happy to give access rights to the plugin's WordPress repository as well. Would you be open for that?
diablodale commented 2016-08-11 17:25:12 +01:00 (Migrated from github.com)

That is ok with me. I will keep any changes I make in branches until you feel I can make changes to master.

I have created a separate branch (in my fork) with the changes I have made for https://github.com/petermolnar/wp-ffpc/issues/56. The work is complete. I only need to do some more testing with multisite. My changes exposed a minor UI issue with admin notices. I want to fix that also so the notices are not confusing.

If I had access rights here, I can create a branch and move/copy the changes from my fork's branch into your branch here. I have never done cross-repro branch copy/merges before, but I read it is easy. ;-) If there is a specific process you want me to follow, please educate me so I can make a smart choice.

That is ok with me. I will keep any changes I make in branches until you feel I can make changes to master. I have created a separate branch (in my fork) with the changes I have made for https://github.com/petermolnar/wp-ffpc/issues/56. The work is complete. I only need to do some more testing with multisite. My changes exposed a minor UI issue with admin notices. I want to fix that also so the notices are not confusing. If I had access rights here, I can create a branch and move/copy the changes from my fork's branch into your branch here. I have never done cross-repro branch copy/merges before, but I read it is easy. ;-) If there is a specific process you want me to follow, please educate me so I can make a smart choice.
Sign in to join this conversation.
No milestone
No project
No assignees
1 participant
Notifications
Due date
The due date is invalid or out of range. Please use the format "yyyy-mm-dd".

No due date set.

Dependencies

No dependencies set.

Reference: petermolnar/wp-ffpc#59
No description provided.