Weird caching problem in multi-domain revo install in Rackspace Cloud Sites environment

I've been struggling with this one for a while, and thought maybe somebody might have some ideas of what to try or look for.

I'm running a 3-domain Revo install in the Rackspace Cloud Sites environment - meaning that the server is completely virtual and running on a multi-cluster platform, probably using their own proprietary clustering system. Which may mean the answer to my problem is "don't do that." But I'm going to try.

It works, except for caching. I keep getting errors like "unable to cache system settings" and "unable to cache context settings." Sometimes the sites work fine despite this. Sometimes you clear the cache and then discover that one or more sites is radically broken (e.g. the Wayfinder menu has disappeared), but then you clear the cache again and it's fine.

I think I've isolated the problem to the one domain that happens to be running on a different cluster from the other two (I've asked for it to be moved to the same cluster, and apparently they can't do that). What appears to be happening is that the Apache user initiated on that domain can't write to cache files that were created by the Apache user on the main domain, and likewise the other way around. Rackspace support assures me that they are treated as the same user and should have no problem writing to the files, but that's not what I'm seeing.

This seems to be creating a sort of cross-cluster race condition (perhaps it should be called a cluster-f***). If the main domain manages to cache the system settings and context settings first, everything is fine - except the problem domain can't cache its context settings, but it appears to work anyway. If the problem domain gets there first, then the main domain can't cache anything because all of the cache files are unwritable, and lots of stuff breaks.

I tried setting the problem domain up with a cache_path context setting to write its cache to its own root directory instead of the core directory for the main domain. This appeared to work for a few minutes, and then I was locked out of the manager completely and had to remove the setting from the database in order to log in again. Even if I can get this to work, that seems to mean that the problem domain cache won't be cleared when the manager clears the cache, although I could write a plugin to do that, but I'm loathe to try this lest I be locked out of the manager again.

So here's my configuration details: PHP 5.3.14 on Apache 2.2 in Linux (not sure which distro, probably CENTOS). MySQL 5.0.77-log. Revo 2.2.6.

In the Rackspace Cloud Sites environment, each domain has its own directory on what looks from my end like a single server, but of course it's not. The main domain and one other are actually on the same cluster and appear to have no problems. The other domain is on a different cluster. I have different index.php files on each domain, which initiate the appropriate context, but the core path setting is the same for all three domains and points to the core on the main domain, which is one level above webroot but still within the root directory for that domain.

Oh, one other note - this problem appeared to start with Revo 2.2.5, and there were some changes to caching in that version that might very well affect this sort of thing. I've looked at the source code for the cache manager, and it uses the umask function, which according to the PHP manual shouldn't be used in multi-threaded environments because it might cause a race condition - well, this environment is not just multi-threaded but actually multi-cluster, which might compound the problem. Why does the cache manager use umask anyway, when the PHP manual recommends against it?

https://forums.modx.com/thread/?thread=80423

Susan, you rock as always. Sorry for not finding that myself - I thought for sure this was such an unusual problem that nobody else would have encountered it! Note to self - there's nothing new under the sun.

Thanks.