memcache session storage, workaround bug with memcache pecl extension

[sthen]

Re ticket #1488384 and I think some others, various people have had problems with memcache being unable to delete keys. It's clearly visible when you sniff the traffic to the memcache server:

delete vgjkahooafjpmp08pl3mjd4sr1 1
CLIENT_ERROR bad command line format.  Usage: delete <key> [noreply]

I've tracked this down. Old memcached versions had a parameter to the "delete" command specifying a timeout which is now rejected. There was some backwards-compatibility fix in memcached which ignores a value 0 in this position but some versions of the memcache PECL extension default to using 1 here. This was supposedly fixed but the fix appears to be incomplete; on occasion this has still been seen with the latest version.

The attached diff sets the value explicitly when delete is used for session and imap cache storage, overriding the default, which fixes the issue for me.

[sthen]

rcube-memcache-delete.diff

[sthen]

A few references about this, it seems likely that some OS packagers have modified the memcache extension to deal with this, but the situation is still something of a mess.

• ​https://bugs.php.net/bug.php?id=58943
• ​https://bugs.php.net/bug.php?id=59260
• ​http://grokbase.com/t/php/php-notes/09bagj7n65/note-94536-added-to-function-memcache-delete
• ​http://www.t3node.com/blog/typo3-caching-framework-throws-client-error-with-broken-php5-memcache-package-from-debian-squeeze/

[alec]

Fixed in 23557f06d13f121a8483376dad1604eb30711a88.