Trailing errors when using space in key

[bpeschier]

While debugging the Django tests I found that pylibmc's flush_all reports an error when you have just set a erroneous key with a space:

>>> c = pylibmc.Client(['127.0.0.1:11211',])
>>> c.set('test', 'value')
True
>>> c.flush_all()
True
>>> c.set('test with a space', 'value')
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
_pylibmc.SocketCreateError: error 11 from memcached_set: SUCCESS
>>> c.flush_all()
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
_pylibmc.SomeErrors: error 19 from flush_all: SUCCESS
>>> 

There seems to be a bit of lag in it, because after a short amount of time the flush will succeed.

This is on pylibmc 1.2.3 with libmemcached 1.0.15 and memcached 1.4.15

[lericson]

Does it work if you retry after a few seconds? Here is my output:

~ % python -m pylibmc
pylibmc interactive shell

Input list of servers, terminating by a blank line.
This was supposed to be a list of tips but I...
Address [127.0.0.1]: 

mc client available as `mc`

>>> mc.set('foo bar', 'abc def')
Traceback (most recent call last):
  File "<console>", line 1, in <module>
ClientError: error 9 from memcached_set: SUCCESS
>>> mc.flush_all()
True
>>> mc.flush_all()
True
>>> mc.flush_all()
True
>>> mc.set('foo bar', 'abc def')
Traceback (most recent call last):
  File "<console>", line 1, in <module>
ClientError: error 9 from memcached_set: SUCCESS
>>> mc.flush_all()
Traceback (most recent call last):
  File "<console>", line 1, in <module>
SomeErrors: error 19 from flush_all: (140620757540112) SERVER HAS FAILED AND IS DISABLED UNTIL TIMED RETRY, host: 127.0.0.1:11211 -> libmemcached/connect.cc:612
>>> mc.flush_all()
Traceback (most recent call last):
  File "<console>", line 1, in <module>
SomeErrors: error 19 from flush_all: (140620757540112) SERVER HAS FAILED AND IS DISABLED UNTIL TIMED RETRY, host: 127.0.0.1:11211 -> libmemcached/connect.cc:612
>>> mc.flush_all()
Traceback (most recent call last):
  File "<console>", line 1, in <module>
SomeErrors: error 19 from flush_all: (140620757540112) SERVER HAS FAILED AND IS DISABLED UNTIL TIMED RETRY, host: 127.0.0.1:11211 -> libmemcached/connect.cc:612
>>> mc.flush_all()
True

[bpeschier]

Yeah, I see the same behaviour. If you flush directly after the spaced-key-insert, you will get the error. If you wait a bit, the flush will succeed.

This is on ASCII-mode only, binary works fine. I see too long keys work as expected (they are validated before going to the server?).

[lericson]

Hm seems to me that the behavior is intended. Weird that it would behave different on UDP, maybe an optimization.

@BrianAker could you chime in on this? I doubt it is to do with anything pylibmc specific.

[bpeschier]

I believe the restrictions on keys are different for the two protocols.

A glance at libmemcached indicates it does check the key (http://bazaar.launchpad.net/~tangent-trunk/libmemcached/1.0/view/head:/libmemcached/storage.cc#L370 and http://bazaar.launchpad.net/~tangent-trunk/libmemcached/1.0/view/head:/libmemcached/key.cc#L68), but I don't see the corresponding error coming back.

[lericson]

Ah of course! Silly me.

-Ludvig telefon

Bas Peschier notifications@github.com wrote:

I believe the restrictions on keys are different for the two protocols.

A glance at libmemcached indicates it does check the key (http://bazaar.launchpad.net/~tangent-trunk/libmemcached/1.0/view/head:/libmemcached/storage.cc#L370 and http://bazaar.launchpad.net/~tangent-trunk/libmemcached/1.0/view/head:/libmemcached/key.cc#L68), but I don't see the corresponding error coming back.

---

Reply to this email directly or view it on GitHub:
#114 (comment)

[lericson]

So is this really an issue? You can enable the behavior to validate keys before, I think that would prevent the protocol-level error.

[bpeschier]

Good question, but I think it's safe to say this is not really an issue. The django test suite is actively trying to "break" memcached by testing invalid keys, which I would say is non-standard behaviour O:) So I think we will have to either make backend-specific tests in Django for pylibmc and python-memcached or change the test suite in a different way.

Thanks for your time!

[edmorley]

Just checking I'm understanding this correctly:

• unlike python-memcached, pylibmc does not verify keys by default (due to the default libmemcached behaviour)
• key verification can be enabled by using the verify_keys pylibmc behavior option, but presumably has a performance impact, so it's common for people to not enable it
• if verify_keys is not enabled, using .set('key with spaces', 'value') results in the key being sent as-is to the server
• if the server receives such a key, it currently handles it poorly (if not using binary mode), causing subsequent commands to fail for a few seconds, when really it should have immediately returned a sensible error code, like happens for the "key too long" case

-> as such this is just a bug in memcached server, which pylibmc can't do anything about, and that the user needs to work around using either verify_keys or by enabling binary mode.

Is this correct?

Thanks :-)