On Tue, 10 Jul 2007, Paul Querna wrote: > Brad Fitzpatrick wrote: > .... > > COMMANDS: (for cmd byte) > > > > get - single key get (no more multi-get; clients should pipeline) > > getq - like get, but quiet. that is, no cache miss, return nothing. > > > > Note: clients should implement multi-get (still important for > > reducing network roundtrips!) as n pipelined requests, the > > first n-1 being getq, the last being a regular > > get. that way you're guaranteed to get a response, and > > you know when the server's done. you can also do the naive > > thing and send n pipelined gets, but then you could potentially > > get back a lot of "NOT_FOUND!" error code packets. > > This is missing the discussion about the GETQ putting the server into > 'cork' mode, and any non-GETQ would uncork it. This would allow the > server to optimize its own IO without nearly as much pain.
That seemed like a server implementation detail/optimization, not something that client authors need to care about. But yes, you're right... I forgot: it needs to be documented that you're not guaranteed a response to a getq cache hit until you send a non-getq command also, which uncorks the server. > Also, as a client author, I really would prefer just having a NOOP or > ECHO command at end of the bulk GETQ, rather than having to special case > the last request. I guess I could just send a GET for a stats key or > something, but that seems weird. The "echo" command is on the jpg. I don't think anybody in the room cared one way or another whether clients did getq*(n-1) + get or getq*n + noop. I figure we'll add the noop/echo command to the server anyway, then clients can choose which feels better to them... noop/echo or saving 12 bytes by special casing last one. Doc updated in svn for both of your comments. - Brad
