Support for Drupal 7 is ending on 5 January 2025—it’s time to migrate to Drupal 10! Learn about the many benefits of Drupal 10 and find migration tools in our resource center.
memcache truncates longer than 250 keys. not good.
Comment | File | Size | Author |
---|---|---|---|
#14 | memcache-sha1-key.patch | 890 bytes | kbahey |
#12 | memcache-md5-key.patch | 891 bytes | kbahey |
#9 | memcache-md5-key.patch | 549 bytes | kbahey |
x.patch | 600 bytes | chx |
Comments
Comment #1
jaydub CreditAttribution: jaydub commentedrelated to #355299: errors like Failed to set key: cache_content-content%3A148498%3A148498
Comment #2
Anonymous (not verified) CreditAttribution: Anonymous commentedyes, can we have this please? we hit a bug in the latest php module, where keys passed to memcache greater than 250 are causing php to segfault. that's a bug a in the C module, but passing anything longer than 250 is a bug in this module.
chx's patch looks good to me, and we're using it in production.
Comment #3
Anonymous (not verified) CreditAttribution: Anonymous commentedwoops, that patch should be:
because the urlencode'd key can be longer than the straight full key.
Comment #4
SwampcritterAny idea on when this patch can be committed w/ justinrandell's modification? I have it deployed for a couple of smaller production sites and so far it has definitely fixed our memcache long key problem.
-- M
Comment #5
ball.in.th CreditAttribution: ball.in.th commentedHi,
Is there a particular reason why the $full_key has to be urlencode()? Does memcache support binary key? In fact, urlencoding could make the key a lot longer. For example, if the key is a string "http://drupal.org/สวัสดีดรูพัลด้วยภาษาไทยก็ยาวเกินแล้ว", urlencode it would make it become "http://drupal.org/%E0%B8%AA%E0%B8%A7%E0%B8%B1%E0%B8%AA%E0%B8%94%E0%B8%B5..." totaling 342 characters.
Comment #6
ball.in.th CreditAttribution: ball.in.th commentedHi,
I've tested memcache with keys in utf8 and it worked fine. So, there's no need to urlencode the key at all.
Comment #7
drewish CreditAttribution: drewish commentedsubscribing
Comment #8
crea CreditAttribution: crea commentedSubscribing.
Comment #9
kbahey CreditAttribution: kbahey commentedThis is a problem.
For the long explanation see very long URL aliases not correctly cached in memcache.
I created a patch in #756926: Extra long URLs combined with unicode causes cid clashes and use it successfully on a large site. The other issue is marked as duplicate of this one.
I am attaching it here again. It is in use on a large site. That site has no prefixes for memcache though.
Comment #10
drewish CreditAttribution: drewish commentedkbahey, why do you urlencode() before md5()ing? it doesn't seem like there's any need.
Comment #11
kbahey CreditAttribution: kbahey commentedNo good reason really other than it was there in the first place. I just took an md5 of whatever was there.
We could take out the url encoding with no ill effect.
What I want people to test really is the prefix stuff. If someone is using prefixes, then can they check if this works or not?
Comment #12
kbahey CreditAttribution: kbahey commentedHere is a better patch.
1. It does not urlencode the URL anymore, it is not needed.
2. It preserves the prefix and bin as they are without URL encoding.
Can someone give it a spin please?
Comment #13
pwolanin CreditAttribution: pwolanin commentedmd5 is not necessarily the most robust hash function - at least use sha1, better sha256.
Comment #14
kbahey CreditAttribution: kbahey commentedHere is the patch with sha1. I don't think we need to go sha256 and risk more CPU usage for an operation that happens for every cache_get/set. Unless someone benchmarks them and finds the difference to be marginal.
Comment #15
Jeremy CreditAttribution: Jeremy commentedSlightly modified version committed to the 7.x branch:
http://drupal.org/cvs?commit=359644
Comment #16
Jeremy CreditAttribution: Jeremy commentedAlso committed to the 6.x branch:
http://drupal.org/cvs?commit=359646