new .net client for memcached
roberto at spadim.com.br
Wed Jul 11 12:52:36 UTC 2007
what about using swig to write client protocol? we just need to select
what language and compile.. no time spend creating one interface for
> This client looks really good for .NET. For instance the open source
> client listed on danga doesn't fail very well when you pull the
> connection on one of the servers in the pool, you get a flood of
> exceptions. This client much more correctly flags the server as down,
> removes it from the list and then checks to see if its back up at a
> later time.
> That alone is really sweet. Using native .NET configs is nice too,
> the class design is also much more extensible. Everyone will have to
> customize the client for their environment and this client will be
> easy customize.
> I would like to add the ability to define different "bins" or groups
> of servers for different cache purposes, instead of having the one big
> list, we can discuss offline. The only other thing i see right off is
> that I'll need to remove the log4net debug calls for our prod
> environment, but that's not a big deal.
> Thank you very much for sharing this code, hopefully we can help
> contribute back, I'll be setting it up and testing this week and next.
> On 7/6/07, *a.* <a at enyim.com <mailto:a at enyim.com>> wrote:
> we could argue which is more complete. my personal opinion is that
> ported code usually doesn't take advantage of the target platform,
> but mirrors an implementation which was tailored for the source
> even if .net and java are similar, a code written for java can under/
> over perform on .net.
> additionally i did not feel comfortable with the architecture of the
> ported code, mainly with the locking and server pool handling.
> the description page on code plex is not finished yet (my bad), so
> let me list the main features of my client
> - it's configurable thru app/web.config, no more 10-20 line init
> codes for the client
> - written specially for .net, not ported, using the latest features
> of the framework
> - better (hopefully) locking providing better throughput
> - uses consistent hashing for keys (based on ketama, found on the
> list some months before)
> - keys are hashed using FNV hash, much faster than md5 and have
> better dispersion than the Object.GetHashCode()
> - operations are factored into separate classes, so they are more
> separated from the main client class, easier manageability and thread
> - more clients -> more options -> more competition -> better clients
> On Jul 6, 2007, at 1:29 PM, Antonello Provenzano wrote:
> > Thank you for the support, but honestly I don't see the
> advantage of
> > using your library rather than Memcached.NET
> > (https://sourceforge.net/projects/memcacheddotnet/), that is more
> > complete and based on the Java client.
> > Cheers.
> > Antonello
> > On 7/6/07, a. <a at enyim.com <mailto:a at enyim.com>> wrote:
> >> hello list,
> >> Previously I mentioned I had to create a client for one of my
> >> projects from scratch.
> >> I'd like to announce that I've released it under a BSD like license
> >> at http://www.codeplex.com/EnyimMemcached
> >> The state of the project is "works for me", but there can be
> bugs in
> >> it, so do not roll out in production before trying it out ;]
> >> If you have questions or comments feel free to comment me
> >> or ask on the list if your question might concern others.
> >> a.
> >> --
> >> enyim.com <http://enyim.com>
> Esta mensagem foi verificada pelo E-mail Protegido Terra
> Scan engine: McAfee VirusScan / Atualizado em 06/07/2007 / Versão:
> Proteja o seu e-mail Terra: http://mail.terra.com.br/
More information about the memcached