noreply semantics with meta commands #868
Comments
|
Thanks for the writeup! Though I wish I were hearing this feedback years ago during the long open period :) I did the new
Think I'm open to a |
## Motivation / Description See: memcached/memcached#868 TL;DR: Memcache noreply can return error responses on write commands, defeating the purpose of the noreply command can causing the response parsing on the socket to become miss-aligned. This implements client-side no-replies. We basically do not send the `q` flag, return immediately without waiting for the response (so there is no roundtrip penalry) and keep a counter of the pending, non-read responses that we need to drop. ## Changes introduced - No not send noreply flag on write commands - Client-side noreply implementation to maintain the fast non-blocking behavior.
|
I accidentally deleted a third note here:
This is less useful if you're just doing a fire-and-forget, but I'm not sure why you'd want to do that for commands where errors would matter. The original |
|
NOP could definitely work. I'll take a look at it. I agree normally you don't need to use flags that can cause errors with noreply. But I'm implementing a python client that supports meta commands, and I wasn't limiting when you could use noreply cas for example. |
|
Got it. I'll give your client a read through out of curiosity. I think noreply cas has a valid use case (batch of cas sets capped and only handle failures), which wasn't possible before, but I still like your Q idea for true fire-and-forget situations. If you don't mind I'll leave this open until I get that figured out (which could be a while). |
|
Sure, I'm totally fine leaving this open. This is the meta commands python client: https://github.com/RevenueCat/meta-memcache-py suggestions/comments are welcome! |
## Motivation / Description See: memcached/memcached#868 TL;DR: Memcache noreply can return error responses on write commands, defeating the purpose of the noreply command can causing the response parsing on the socket to become miss-aligned. This adds no-op meta command to no-reply write requests. We can return immediately without waiting for the response (so there is no roundtrip penalty) and keep a counter of the pending expected no-op responses. The next non-noreply command will read and ignore responses until the no-ops have been read, and proceed to read the right response to the new command. ## Changes introduced - Send no-op after noreply write commands - Response reads will drop pending responses until the no-op response when noops are expected in a connection.
## Motivation / Description See: memcached/memcached#868 TL;DR: Memcache noreply can return error responses on write commands, defeating the purpose of the noreply command can causing the response parsing on the socket to become miss-aligned. This adds no-op meta command to no-reply write requests. We can return immediately without waiting for the response (so there is no roundtrip penalty) and keep a counter of the pending expected no-op responses. The next non-noreply command will read and ignore responses until the no-ops have been read, and proceed to read the right response to the new command. ## Changes introduced - Send no-op after noreply write commands - Response reads will drop pending responses until the no-op response when noops are expected in a connection.
* Implement noreply flag client-side for write commands ## Motivation / Description See: memcached/memcached#868 TL;DR: Memcache noreply can return error responses on write commands, defeating the purpose of the noreply command can causing the response parsing on the socket to become miss-aligned. This adds no-op meta command to no-reply write requests. We can return immediately without waiting for the response (so there is no roundtrip penalty) and keep a counter of the pending expected no-op responses. The next non-noreply command will read and ignore responses until the no-ops have been read, and proceed to read the right response to the new command. ## Changes introduced - Send no-op after noreply write commands - Response reads will drop pending responses until the no-op response when noops are expected in a connection. * Add test
Describe the bug
Errors are always returned in metacommands with noreply
qflag.This is the correct described behavior according to the documentation, but I want to challenge the current behavior as it is inconsistent with previous protocols and makes implementation and usage extremely hard.
The biggest purpose of noreply flag is "fire and forget". Instead of awaiting for response, you can send something on the wire, and keep going without waiting for the roundtrip. You can, for example, implement rough counters with this, if the command is lost or causes error, not a big issue, but you don't need to wait for the roundtrip.
In previous text protocol, noreply could potentially return error responses ONLY if the command was malformed (as there is no guarantee the noreply marker could be properly processed), but any other errors like CAS check failures, add/replace existing/not existing, etc were never returned as errors. This is what the documentation says:
meta commands on the other hand, declare:
Saving data sent back is arguably a strange reason to use this, as a
"HD\r\n"response is a mere 4 bytes. Like I said before, the biggest use case for me is to implement fire-and-forget commands, that do not need to wait for the roundtrip to the server (at the expense of knowing about errors).The current choice of return nothing for success, error otherwise makes implementation very hard:
Suggested solution:
a) Make noreply
qflag behave as before. No errors other than when request is malformed will be returned.b) If keeping backward compatibility is preferred, add a new
Qflag that implements this behavior.I think that a) makes more sense, as I highly doubt anybody is finding the current behavior for
qflag usable, but I could live with a separate flag of course.To Reproduce
System Information
Tested in memcache 1.6.12
The text was updated successfully, but these errors were encountered: