-
-
Notifications
You must be signed in to change notification settings - Fork 817
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
(dev/core#316) Fix crash on Memcache systems when session key involves whitespace #12640
(dev/core#316) Fix crash on Memcache systems when session key involves whitespace #12640
Conversation
(Standard links)
|
(CiviCRM Review Template WORD-1.1)
Regarding this:
Agree it should be OK as-is. The impact here is changing the effective-key used in memcache for anything involving a space. However, if the effective-key had a space in it before, then it was broken already, and the cache wouldn't be filled. (Update: My comment had a grain of truth... but was wrong/incomplete. The change also impacts non-memcache systems where spaces were fine. Never-the-less, I still think it's safe for the more general/obvious reasons... typical use-case: sysadmin upgrades to a new release with this patch, and the upgrader clears out all manner of caches+sessions per norm. Worst use-case: sysadmin manually applies patch on a non-memcache system... because they're crazy... and it has a momentary, de-facto impact of invalidating some caches+sessions. The old cache-data exists but should cycle out eventually.) @xurizaemon since this is a recent regression, could you rebase the patch to target the RC branch ( |
Since this method is performance related and called frequently, no need to recalculate results from preg_replace_callback() with the same inputs.
2278143
to
8720352
Compare
@xurizaemon Thanks for this - your code almost works 👍 I discovered that |
Have pushed an additional commit that would hopefully catch this ... let me know if that works! @totten note that the previous changes weren't sufficient 😞 |
@xurizaemon One further issue I've run into is that Extensions cannot be installed while Memcached is being used:
As you can see,
FWIW, turning Memcached off allows me to install Extensions. |
This is replaces 95b6567. The intent is to have a delimiter every ten chars so that it's easy to read/confirm the length of the string. The delimiter was space, but this became a longer encoded char (`-20`) and threw off the numbers. Switching to dash just gives a different encoded char. To get the counts right, it needs ot be a pass-through char... like underscore.
Taking @christianwach's confirmation and a quick test I did locally, we've now got two For the @christianwach, I've tried on D7 and WP with 5.5 and haven't been able to replicate the problem with extension activation. I'll try again with 5.4+patch, and maybe we should have another issue for that? Flagging merge-on-pass. |
Thanks @xurizaemon for fixing this! |
@christianwach just as an aside we are digging into adopting Redis off the back of this cache cleanup (which unfortunately stung you) - hopefully we'll do some performance tests soon |
Apologies in advance if there's too much debugging info below - I've tried to debug the Install Extension process but I get lost in the intricacies of
Debugging further up the line in
Here's what
So, somewhere at some point, the @totten Can you suggest how I might be able to pinpoint what's going on? |
@totten A little more info: when Memcached is not being used, the URL sequence is as follows:
When Memcached is being used:
As I said, I'll happily test further given pointers as to where to keep digging. |
I've filed the extension-install issue as https://lab.civicrm.org/dev/core/issues/336 |
Overview
As reported @ https://lab.civicrm.org/dev/core/issues/316, there seems to be an issue with Memcache compatibility - keys generated by Cache::cleanKey() permit whitespace, which Memcache does not allow.
This patch addresses the bug and also micro-optimizes some cache logic.
Before
cleanKey()
is called twice in a row.After
cleanKey()
is called once.Technical Details
Changes cache keys, so may indicate that we should run a cache reset. (But if caching is sane, that shouldn't be required?)
Comments
Note for reviewing: Since this issue was reported by a user who upgraded to an official release, there's an implication to me that we don't have memcache as part of our test matrix. This would then require manual testing (perhaps by the affected user) to confirm the fix (or I guess inclusion of memcache in our test matrix).