Changes have been made in Git for this ticket:

Bug #10123: Memcache flag fixes.
pecl/Memcache version 3.0.3 upwards started to reserve the first 16 bits

Signed-off-by: Michael M Slusarz <slusarz@curecanti.org>

  2 files changed, 13 insertions(+), 7 deletions(-)
http://git.horde.org/horde-git/-/commit/cc662ba8c894b0f967c156b4f3e74156d6656142

Michael, the previous patch is important to keep Memcache working with 
recent pecl/Memcache as expected.

It seems that pecl/Memcache is reserving the last 16 bits now (started 
on version 3.0.3 
http://pecl.php.net/package-info.php?package=memcache&version=3.0.3)

Also, according to the Memcache protocol 
(https://github.com/memcached/memcached/blob/master/doc/protocol.txt#L155) we 
can use up to 32 bits since version 1.2.1 (Nov 2006)

I've been working with Gonçalo on this so I'll answer you.

With the last patch you made you're right. The problem here is that 
every key will cause a cache miss. This returns the platform into a 
cold cache state which isn't an expected behavior from a minor 
upgrade. We now have upwards 10G of cache data so I think you can 
understand how regenerating this data can make a performance hit.
You're very right, but we use memcache to also store sessions and that 
implies logging everyone out. I agree that memcache isn't the right 
solution to store sessions but for our case it seems the best and it's 
an horde conf.

As Gonçalo said the warning would make sysadmins aware of these 
implications and the patch only makes the transition smoother.

Changes have been made in Git for this ticket:

Bug #10123: More correct fix for ignoring old values
Need to completely remove the item from the results list, since it is in
the old format and won't be pieced together correctly.

  1 files changed, 14 insertions(+), 1 deletions(-)
http://git.horde.org/horde-git/-/commit/861499b90afc4686bd1b471bbaf18f74d2cd4532

How?  If I read the code correctly, this new code will simply cause a 
cache miss.
No need to convert these values.  Memcache, as the name itself 
implies, is a cache.  If data objects suddenly go missing, this is an 
expected occurrence.

Changes have been made in Git for this ticket:

Request #10123: part_count might be -1, which we should ignore

  1 files changed, 1 insertions(+), 1 deletions(-)
http://git.horde.org/horde-git/-/commit/09fdf8b206ceebf097ab3ce2ef8b5b2fe049eb5d

Yep, its ok.
I think that it should be sent to dev (or the appropriate place), a 
message to warn people that starting  to use this code will bring 
unexpected results if they have large objects on memcache.

We have made (untested yet) for ourselves a temporary patch to convert 
old large objects to the new flag system. Attached the temp patch

Your patch did not apply cleanly, so I had to go through by hand and 
make the necessary changes.  Could you test and make sure I 
transferred the changes correctly?

Changes have been made in Git for this ticket:

Request #10123: Use memcache flags to keep track of large objects
Signed-off-by: Michael M Slusarz <slusarz@curecanti.org>

  2 files changed, 37 insertions(+), 58 deletions(-)
http://git.horde.org/horde-git/-/commit/63dee150d1309f6909b6d3102c68a0f1b3c64d7b

Tested the patch with and without large objects, and everything seems to work

As discussed here:
http://lists.horde.org/archives/dev/Week-of-Mon-20110523/026224.html