On Oct 23, 9:36 pm, dormando <dorma...@rydia.net> wrote: > Try it without the '0' in there. The delete expiration was (the only?) > incompatible change from 1.2.8 to 1.4.0. It's gone now.
What was the reason to *break* the protocol then? Couldn't memcached just ignore the expiration time here? What happens now is: a client sends "delete key 0 noreply". Server answers "ERROR", but the client doesn't expect the reply (because of "noreply"). The client then sends some other command, say "set bla-bla", now reads "ERROR", then sends "get bla-bla", reads "STORED", etc. I.e. all replies are "shifted" because of that unexpected extra "ERROR". What was the point of that? The commit in question is 5da8dbab2a815c00617ab60b641391ada8d96f40. Can it be fixed?
