You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
I'm not very familiar with the memcached protocol, and it's not really described in the protocol docs (other than in the getq) case, but it sounds:
quiet ops suppress non interesting responses
quiet ops delay starting to send a response until a non quiet response is sent.
Since this isn't happening in the above, the interesting responses from the dalli.multi block only get sent when the get request is made & dalli ends up returning the response from the failed delete as the get request.
Ideally (for me at least). multi would take care of this by sending a noop request and reading any response data, but this would mean that all existing uses of multi would incur one extra request. At the very least this should be called out in the docs, ideally with the addition of a read_responses option to multi.
The noop method on Server nearly does the right thing, although it assumes that all response are KV responses whereas they could be of any type (in addition this functionality isn't exposed on Client).
Happy to work on this if a direction is agreed.
The text was updated successfully, but these errors were encountered:
It seems the response is available with the socket but because the multi command doesn't end up reading it. It gets read with the next request according to bin protocol and only the response to the last request is returned.
Dalli's multi method doesn't seem to handle responses as it should. The following snippet demonstrates the problem I've observed
I'm not very familiar with the memcached protocol, and it's not really described in the protocol docs (other than in the getq) case, but it sounds:
Since this isn't happening in the above, the interesting responses from the
dalli.multi
block only get sent when theget
request is made & dalli ends up returning the response from the failed delete as the get request.Ideally (for me at least).
multi
would take care of this by sending a noop request and reading any response data, but this would mean that all existing uses of multi would incur one extra request. At the very least this should be called out in the docs, ideally with the addition of aread_responses
option tomulti
.The
noop
method on Server nearly does the right thing, although it assumes that all response are KV responses whereas they could be of any type (in addition this functionality isn't exposed on Client).Happy to work on this if a direction is agreed.
The text was updated successfully, but these errors were encountered: