Indeed, I was somehow wondering "why a Q for no reply?" ;-) Anyway, it makes sense. I guess my issue is fully client side then.
cheers, Jean-Charles On 25 fév, 18:38, Dustin <[email protected]> wrote: > On Feb 25, 6:29 am, JC <[email protected]> wrote: > > > trying to investigate an issue on the replicated delete of > > libmemcached, I found out that the no reply delete command is replying > > something in case of error (as "key not found"), which makes it pretty > > hard for the client library to follow the messages count and not work > > as expected in certain conditions ... > > It's less confusing if you don't refer to it as "no reply". "no > reply" is a bad idea. We refer to these as "quiet" commands because > under normal circumstances, they don't say anything. > > It's normal for a delete to delete something, so that's quiet. > > It's not normal for it not to delete things, so there's a response. > > > is it the expected behaviour? > > Yes, you don't follow message counts, you track opaque IDs and send > a terminal not-quiet command you can use to infer success of every > quiet command that didn't respond. > > This gives you the performance benefits of avoiding processing of > data, while guaranteeing that you can know the result of every command.
