Hm, adding support for noreply shouldn't be that hard, you could probably
hack it in yourself:
On line 343 in Memcached.cs, add a parameter to the private store method,
"bool quiet" or something, add "noreply" to the commandlines if it's true,
and then change the return statement on line 383 to "return
quiet?"":socket.ReadResponse();". Then you need to fix the three private
store methods on lines 320, 325 and 330 to pass false to the method you just
changed, and you need to add a function that looks like this:
private void storequiet(string command, string key, bool keyIsChecked,
object value, uint hash, int expiry) {
store(command, key, keyIsChecked, value, hash, expiry, 0, true);
}
...and finally add the range of overloaded public methods that you need, I'd
probably just create a bunch of SetQuiet methods, because then you know they
will never return anything and that skipping reading from the socket is
safe. If you want it for add or replace or cas, the server might return
something, and that complicates it a bit. I don't know how fast the Read
method on a buffered network stream terminates if there's nothing to read.
If there's any delay, then using noreply does essentially nothing for
performance, and that's not something I would want in the client.
I could probably add the above to the project, but then you would have to
convince me that there's a legitimate usecase for noreply. :-)
/Henrik Schröder
On Thu, Feb 11, 2010 at 01:49, Henrik Schröder <[email protected]> wrote:
> I'm maintaining that one, although since it just works fine there hasn't
> been much to do with it lately. I should get around to implementing the
> binary protocol sometime, but so far I haven't had the time or the need to
> do so, and the lack of a proper windows version of the server makes it even
> less pressing.
>
> What would you need noreply for? When I read through the protocol specs it
> seemed a kind of flaky feature that would be hard to implement right in the
> client. If you're concerned about the performance of having to wait for a
> reply you're not interested in, you could try moving all your bulk sets to
> the built-in .Net threadpool instead, that should give you approximately the
> same results.
>
> I've thought about doing a parallell multi-set, but for the bulk version
> where you don't care about results, I'd rather implement it using the quiet
> binary commands than the ascii noreply command.
>
>
> /Henrik
>
>
> On Wed, Feb 10, 2010 at 23:37, Jeremy Dunck <[email protected]> wrote:
>
>> I'm looking for a .Net client that's actively maintained, preferably
>> with noreply support.
>>
>> This one looks to be maintained: http://code.google.com/p/beitmemcached/
>>
>> Did I miss any others?
>>
>> BeITmemcached doesn't seem to support noreply.
>>
>> Thanks!
>>
>
>
