I wrote a bunch of tests for Trond's new basket of quiet commands,
verifying that they all work as expected.
However, I don't think the semantics are correct. In particular,
this seems to behave differently from the getq command already
established.
getq was defined to not be quiet in al
Hi!
I personally think that the behavior of not responding at all is okay
since this is for complementing the no-reply mode but you do have
a point about the relationship with getq...
Here's a thought, could we separate the set commands?
Cheers,
Toru
On Mon, Jan 26, 2009 at 1:47 PM, Dustin wr
On Jan 25, 10:13 pm, Toru Maesaka wrote:
> I personally think that the behavior of not responding at all is okay
> since this is for complementing the no-reply
I never particularly liked the no-reply mode for roughly the same
reason. I think specifically supressing any status, even the rare
Dustin wrote:
On Jan 25, 10:13 pm, Toru Maesaka wrote:
I personally think that the behavior of not responding at all is okay
since this is for complementing the no-reply
I never particularly liked the no-reply mode for roughly the same
reason. I think specifically supressing any
> In the binary protocol, we can get both the efficiency gains of
> sending commands that are likely to be successful, and still be able
> to handle specific failure cases due to having opaques that can map
> back to the requests.
True. It definitely sounds wasteful to not take advantage of this
Yeah, my main complaint about the original 'noreply' code is that the
error handling was completely FUBAR. I'm sure someone somewhere will want
a noreply command that never gives them errors, but that's really really
broken.
+1 to having it crap back errors.
-Dormando
On Mon, 26 Jan 2009, Toru
On Feb 1, 2:16 am, dormando wrote:
> Yeah, my main complaint about the original 'noreply' code is that the
> error handling was completely FUBAR. I'm sure someone somewhere will want
> a noreply command that never gives them errors, but that's really really
> broken.
>
> +1 to having it crap bac
On Sun, Feb 01, 2009 at 02:16:55 -0800, dormando wrote:
> Yeah, my main complaint about the original 'noreply' code is that the
> error handling was completely FUBAR. I'm sure someone somewhere will want
> a noreply command that never gives them errors, but that's really really
> broken.
Being th
On Feb 1, 9:38 am, Tomash Brechko wrote:
> throw it away. But once the result is being thrown away, why send it
> in the first place? This also hurts streaming greatly, as as of now
> memcached pushes every "STORED" reply in a separate network packet...
I agree with this -- if there's a wa
