We also have this error when deleting. We are using Ubuntu 9.10

Please fix this. Thanks.

We are also having the issue.  Will try the work around.
Centos 5.4

I am also seeing this error on Centos 5.4 with memcache 1.4.3

A patched version to workaround the delete bug is here:

http://phpmemcachepatch.googlecode.com/files/memcache-2.2.5b.tgz

The protocol has been changed between 1.2 and 1.3:
  up to 1.2: http://github.com/memcached/memcached/blob/1.2.8/doc/protocol.txt
  # delete <key> <time> [noreply]\r\n

  since 1.3: http://github.com/memcached/memcached/tree/1.3.2
  # delete <key> [noreply]\r\n

and since memcached 1.4.3 the delete command will fail if a <time> was given.

@dweller:
Your patch doesn't work correctly: If you have a memcached 1.2.x the parameter '$timeout' will be ignored on Memcache::delete :(

To fix this check the server version first.
Do have have a patch for memcache 3.0.4, too?

-> I think the second parameter of Memcache::delete have to completely removed in the future.

I'm seeing the same behaviour in beta versions > 2.2.5 stable, although these versions require a different patch to the one mentioned above for the stable version 2.2.5 

I have patched the problem in version 3.0.4. You can download the patched PECL memcache 3.0.4 from here:

http://www.gosquared.com/labs/memcache/memcache-3.0.4_patched.tgz

By the way, this issue should be resolved by a backwards compatibility fix in version 1.4.4 of memcached, obtainable over at http://memcached.org/

Please note that the 1.4.4 memcached release *doesn't* fix 
this problem if you were actually using the timeout option to 
delete in your code.  If that's the case, you'll need to 
change your code as well.

Also having this issue on Mac OSX 10.6
memcache 2.2.5 stable
memcached 1.4.4

Works if I pass 0 as the timeout param but if anything greate than 0 is passed then it returns false.

Yesterday I tested memcached 1.4.4 and was not able to delete anything. Turns out that pecl/memcache 3.0.4 defaults to timeout 1 for deletes instead of 0.

strace of PHP-process deleting a key without specifing timeout:
sendto(3, "delete user:1354381 1\r\n", 23, MSG_NOSIGNAL, NULL, 0) = 23

Specifing the timeout to 0 sends an proper command:
sendto(3, "delete user:1354381\r\n", 21, MSG_NOSIGNAL, NULL, 0) = 21

Turns out memcache.c uses "value" instead of "exptime" when running deletes and "value" is defaulted to 1(probably to be used with increment/decrement).

Code:
-----
long value = 1, defval = 0, exptime = 0;
....
if (deleted) {
if (zend_parse_parameters(ZEND_NUM_ARGS() TSRMLS_CC, "z|l", &keys, &value) == FAILURE) {

Proposed fix:
-------------
if (zend_parse_parameters(ZEND_NUM_ARGS() TSRMLS_CC, "z|l", &keys, &exptime) == FAILURE) {

The proposed fix from andrer is not complete, the delete 
functions deeper down in the function have to be changed 
from value to exptime:

memcache.c:
static void php_mmc_numeric(INTERNAL_FUNCTION_PARAMETERS, 
int deleted, int invert) /*

if (mmc_object == NULL) {
    if (deleted) {
	if (zend_parse_parameters(ZEND_NUM_ARGS() TSRMLS_CC, 
"Oz|l", &mmc_object, memcache_pool_ce, &keys, &exptime) == 
FAILURE) {
	    return;
	}
    }

else {
    if (deleted) {
	if (zend_parse_parameters(ZEND_NUM_ARGS() TSRMLS_CC, 
"z|l", &keys, &exptime) == FAILURE) {
	    return;
	}
    }
}

if (Z_TYPE_P(keys) == IS_ARRAY) {
    while (zend_hash_get_current_data_ex(Z_ARRVAL_P(keys), 
(void **)&key, &pos) == SUCCESS) {
	zend_hash_move_forward_ex(Z_ARRVAL_P(keys), &pos);
	if (deleted) {
	    pool->protocol->delete(request, request->key, 
request->key_len, exptime);
	}
    }
}
else {
    if (deleted) {
	pool->protocol->delete(request, request->key, 
request->key_len, exptime);
    }
}

NOTE: This is not the full function, just the parts that got 
value changed into exptime!

This option has never worked on any version of memcached.  
Deletes have always been immediate.  Timeout means something 
entirely different from what it's documented to do.

All you have to do is try the existing code against an older 
version to verify that.

Applying this fix and adjusting the documentation to point out 
that it's unused and has never done what was intended is the 
right thing.

I will work with Pierre on the proper way to deal with BC breaks and get this fixed.

I'm having the same problem.
FreeBSD 7.2
memcached-1.4.4
pecl-memcache-3.0.4

I added in the version checking code and then spent some time trying to create the bug.  However, I noticed that this BC break has been fixed in memcached-1.4.4: you can pass a value of 0 and the server will process the request as normal.

Since this is a 1.4.3 only issue, I am moving this ticket to won't fix.

Sorry, today update our memcache servers from 1.2.8 to 1.4.5 and got those messages. Client version - 3.0.3

The backwards compatibility exists only for a timeout value of 0.

Consider the following example:
Trying 127.0.0.1...
Connected to localhost.localdomain (127.0.0.1).
Escape character is '^]'.
set foo 0 60 1
a
STORED
delete foo
DELETED
set foo 0 60 1
a
STORED
delete foo 0
DELETED
set foo 0 60 1
delete foo 1
CLIENT_ERROR bad data chunk
ERROR

Link to release notes:
http://code.google.com/p/memcached/wiki/ReleaseNotes144

Why is this marked as WONTFIX, when this is still a problem?  This code fails:

    $memcache = new Memcache;
    $memcache->connect("tcp://localhost:11211/");
    $memcache->delete("blabla");

....with the same CLIENT_ERROR:

[Thu Jun 03 00:28:30 2010] [error] [client 192.168.1.22] PHP Notice: 
MemcachePool::delete(): Server tcp://localhost:11211/ (tcp 11211, udp 0) failed
with: CLIENT_ERROR bad command line format.  Usage: delete <key> [noreply]\r\n
(0) in [.....]

How can this be considered anything but a regression?  This code used to work, now it doesn't.  All required arguments are present.

(pecl memcache 3.04 and memcached 1.4.5)

I was testing it on the 2.2.5 version.  I didn't realize that it was failing on the 3.0.x version.  I will fix it there then.

A patch was submitted in ticket #17566 that resolved the issue for the 3.0.x version.

I'm still getting the same error using the same 3 lines of code mentioned by "pizza" above for:
memcached 1.4.5
pecl-memcache 2.2.5
ubuntu 9.04

In fact, I'm getting it with pecl-memcache 3.0.4 beta as well.

Sorry for getting a little bit spammy but it DOES seem to work for pecl-memcache 2.2.4

This bug has been fixed in SVN.

In case this was a documentation problem, the fix will show up at the
end of next Sunday (CET) on pecl.php.net.

In case this was a pecl.php.net website problem, the change will show
up on the website in short time.
 
Thank you for the report, and for helping us make PECL better.

http://pecl.php.net/bugs/bug.php?id=17566