[RCD] Trouble with memcached, debian, etc. -- sort of fixed in rcube_session.php?

Rob Sheldon rob at associatedtechs.com
Thu Jan 5 10:11:40 CET 2012


Hi,

Finally decided to get memcached up and running with Roundcube -- 
awesome work there.

I ran into a problem getting it to go at first though. Turned on all 
the logging in memcache and found this relevant bit:

<28 get d5f4fbf9a78ea7c63f2919f1ba544fa0
> FOUND KEY d5f4fbf9a78ea7c63f2919f1ba544fa0
>28 sending key d5f4fbf9a78ea7c63f2919f1ba544fa0
>28 END
28: going from conn_parse_cmd to conn_mwrite
28: going from conn_mwrite to conn_new_cmd
28: going from conn_new_cmd to conn_waiting
28: going from conn_waiting to conn_read
28: going from conn_read to conn_parse_cmd
<28 delete d5f4fbf9a78ea7c63f2919f1ba544fa0 1
>28 CLIENT_ERROR bad command line format.  Usage: delete <key> 
> [noreply]

...which eventually led me to 
http://www.php.net/manual/en/memcache.delete.php where this problem is 
mentioned in comments. The PHP docs there specifically say not to 
include the timeout parameter when calling memcache->delete(), but 
unfortunately, due to a bug in the current php5-memcached package in 
Debian, not including the parameter causes php to automatically append a 
"1" to the end of the delete command, which breaks memcached.

In rcube_session.php, I mucked about with the first line of 
mc_destroy(), changing it to:

     $ret = $this->memcache->delete($key, 0);

...which makes everything happy, despite being incorrect.

I searched the dev- and users- mailing list archives and didn't find 
any other references to this particular problem, so I'm just mentioning 
it here in case anybody else gets bitten by it.

Thanks,

- R.

-- 
[__ Robert Sheldon
[__ Founder, No Problem
[__ Information technology support and services
[__ (530) 575-0278
[__ "You must be the change you wish to see in the world." -- Mahatma 
Gandhi
_______________________________________________
List info: http://lists.roundcube.net/dev/
BT/aba52c80



More information about the Dev mailing list