no reply patch

Tomash Brechko tomash.brechko at gmail.com
Tue Feb 26 12:07:39 UTC 2008


On Tue, Feb 26, 2008 at 02:51:37 -0800, hachi wrote:
> It's late and so I can't talk to dormando about this for a few hours, 
> but a couple days ago I backed out your noreply patches from the 
> memcache perl client because they were causing the client to hang using 
> a memcache server unaware of 'noreply'. I haven't investigated the 
> situation beyond that yet, but I think this calls for some better 
> testing of the noreply patches.

Sure you can't use 'noreply' in the client together with the server
that doesn't understand it---the client will deadlock eventually: it
expects no replies, but server sends (syntax) ERROR for commands with
'noreply'.  I thought that only the patch for the server has been
accepted, not the patch for Cache::Memcached.  The latter patch was
mainly the proof of concept, it enables 'noreply' unconditionally.
Since there wasn't any sign back then that it is going to be accepted,
I didn't add any knob to selectively enable 'noreply' then.

C::M::F allows the user to enable 'noreply' per server, which is the
right thing to do.

While I want C::M to be supported as a reference implementation, I
think you may omit 'noreply' feature from it.  Adding it would call
for per server knob, which in turn would call for { option => value }
syntax for address list (currently it's only 'server' or ['server',
$weight] pair).  Not a lot of work (though some of documenting), but
I'm not inclined to do it now :(.


-- 
   Tomash Brechko


More information about the memcached mailing list