Hi guys, I'm getting a rather strange behaviour when I try to issue a get-multi on memcached, so I'm not sure this is a problem with my understanding of how the protocol was specified or if it's an issue with either pylibmc or libmemcached.
What I expect: As I understand it, for multi-get, the expected communication is: 1. The client sends a getq/getkq for each desired key, in a batch; 2. The client sends a no-op request, to signal that there are no more keys to request for; 3. The server stacks the previous requests, and retrieves all existing keys within the requested ones; 4. The server responds with all retrieved keys with getq/getkq responses, in a batch; 5. The server sends a no-op response, to signal that there are no more keys to send. However, after trying to follow this behaviour in a proxy I'm building, this order of interactions is not being respected; So, what I did afterwards, to assert that something strange was going on, was to fire up Wireshark and listen for memcached requests and responses. Here's a sample of the request and response blocks sent between the client and the server: http://pastebin.ubuntu.com/1679323/ This was tested with pylibmc, in binary mode, and after setting "foo" to "bar", and "foo2" to "bar2", I tried to multi-get "foo" and "foo2". I also tested with more keys after this sample, and this is the behaviour I'm getting: 1. The client sends a getkq for each desired key, in a batch; 2. The server sends the getkq response for the first key; 3. The client sends (and the server reads) the no-op request; 4. The server sends the rest of the keys as getkq responses, in a batch; 5. The server sends the no-op request. This is really weird for me, since the first key value is responded without the server even having received the no-op request. So, I have two questions: 1. Is my understanding of how the protocol works, for multi-get, correct? The documentation I found for it ( http://code.google.com/p/memcached/wiki/BinaryProtocolRevamped) doesn't seem very up-to-date, and doesn't respect that, but I've read somewhere else (and experimented with) that no-ops are the blocks that signal an end-of-batch; 2. If my understanding is right, then is this a problem in the server or in the client? I'm guessing it's in the server, since it starts responding without even getting the no-op request. I can provide more complete details of this interaction data (with timestamps included), if you need me to. Thanks for the help, Diogo -- --- You received this message because you are subscribed to the Google Groups "memcached" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. For more options, visit https://groups.google.com/groups/opt_out.
