Active .Net client? noreply?

[Jeremy Dunck]

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!

[Jozef Sevcik]

Enyim, but I'm not sure about noreply.

http://enyimmemcached.codeplex.com/

However, there seems to be last commit from Dec 2008

[Perry Krug]

I've been in touch with the Enyim developer directly, sounds like he's still actively engaged with the project even if there haven't been any major updates as of late.

There's also a client maintained within Sourceforge: http://sourceforge.net/projects/memcacheddotnet/

[a.]

hi

yeah, no new commits, mostly because it "just works" :)

no reply is not supported yet, but will be soon (tm), and i'm working on the binary protocol as well

additionally, i'm moving away from codeplex to github: http://github.com/enyim/EnyimMemcached

a.

[Dustin]

On Feb 10, 2:37 pm, Jeremy Dunck <jdu...@gmail.com> wrote:
> I'm looking for a .Net client that's actively maintained, preferably
> with noreply support.

What is your goal with noreply?

If you're having a performance problem you hope to solve with it,
you're better off with binary protocol and quiet commands -- this will
make it possible to be aware of and understand failures. You can read
about how I used this technique to improve performance here:

http://dustin.github.com/2009/09/23/spymemcached-optimizations.html

It doesn't specifically describe the semantic problems with
noreply, but you can infer the difference.

[Henrik Schröder]

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

[Henrik Schröder]

I would definitely stay away from that java port if I were you, unless it's been updated recently. The whole reason for us writing the BeITMemcached client in the first place was that we were using the java port, but it would suddenly start throwing lots and lots of errors. When we tried to understand how it worked so we could fix it, we realized that it was a very sloppy least-effort port of a java client, and that it would be much less work to write a good .Net client from scratch instead.


/Henrik

[Henrik Schröder]

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

[Dustin]

On Feb 10, 5:27 pm, Henrik Schröder <skro...@gmail.com> wrote:
> 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. :-)

It's not just use cases, it's bugs. There are times when a response
might come back even though the client intended to send a noreply. We
had a case where it was, from the server point of view, a malformed
request. The client thought it asked for noreply. The server was
getting replies, and now the whole thing is out of sequence and you
just have to hang up.

I'd just think that if there's an error performing an operation,
it's OK to say what that error is. We fixed that in the binary
protocol. :)