no reply patch

[hachi]

Tomash,

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.

The purpose of this email is mostly to make sure you and anyone using 
trunk is aware of this. If you happen to have any useful insight into 
this problem with this little information I'd love to hear it though.

Cheers,
hachi

Tomash Brechko wrote:
> On Mon, Feb 04, 2008 at 19:14:21 -0800, Brian Aker wrote:
>   
>> The patch looks fine, though I think you should move this:
>>
>> +    if (c->noreply) {
>> +        c->noreply = false;
>> +        conn_set_state(c, conn_read);
>> +        return;
>> +    }
>> +
>>
>> ... to being after the verbose if () since without it debugging  
>> problems is going to be a real pain.
>>     
>
> Thanks for looking into this.  Re your comment, the piece
>
>     if (settings.verbose > 1)
>         fprintf(stderr, ">%d %s\n", c->sfd, str);
>
> is the debug message about what will be send to the client.  But with
> 'noreply' nothing will be send, so I avoid this message too.  Also,
> not seeing the result actually stresses the fast that with 'noreply'
> you can't be sure of the command outcome ;).
>
> It could be implemented either way of course, but to my personal taste
> (have no technical reasons) this doesn't have to be fixed.  Thanks
> anyway.
>
>
>   
>> One thought I had with this is that you could use the token you have  
>> added to the server as an additional action verb for future commands.
>>     
>
> Indeed, the 'more' keyword I mentioned in other mail may be used in
> this place, as it is mutually exclusive with 'noreply'.
>
>
>