Share

.NET memcached client library

Project News for .NET memcached client library

  • clientlib 1.1.5 released

    (from the changelog)

    7 June 2007 (TG)
    -Bugfix. Applied a patch from a contributer (thanks Dave Peckham!) that
    fixes a bug where we don't get the proper size of the buffer.
    In many cases the code would still work fine, but you may
    have experienced periodic errors when working with very large
    objects, or seeing wasted space on your memcached servers.

    2007-06-07 15:45:19 UTC by timiscool999

  • clientlib 1.1.4 released

    21 November 2006 (TG)
    Signed assembly
    I added a keyfile to the solution so that the client library
    can be strongly typed. There may be some debate whether or
    not the key should be secret, but this is just easier this
    way. If people are worried about a modified assembly file
    I can start posting MD5 or SHA1 hashes of the binaries
    on the project page.

    2006-11-22 00:07:34 UTC by timiscool999

  • clientlib 1.1.3 released

    21 November 2006 (AR)
    -Bugfix. Workaround incorporated to work around the bug in
    BufferedStream. BufferedStream calls Seek() on streams it
    wraps even if the underlying stream does not support Seek()
    (such as NetworkStream).

    21 November 2006 (TG)
    Upgrade. Upgraded the log4net libraries to 1.2.10. Split the /lib
    folder into a 1.1 and 2.0 directories.

    2006-11-21 16:48:18 UTC by timiscool999

  • Migrated from CVS to SVN for repository

    Should have done it a long time ago, but the pain was finally bad enough when a developer offered to make a patch but said "I don't have CVS installed on this machine."

    2006-11-21 16:01:21 UTC by timiscool999

  • clientlib 1.1.2 released

    -Performance. Turns out that the thorough (sp?) logging throughout the
    library was part of its performance downfall :). There
    was a lot of string concatenation and hashtable lookups,
    which by themselve don't really do much. However, if you
    Do 100,000 hashtable lookups (because all the messages
    are internationalized), and 50,000 string concatenations
    it starts to all add up. I wrapped every logging statement
    with a boolean lookup on log4net which can check to see
    if we're even going to log the message, and if not, don't
    even do the work involved in logging. If you turn off
    logging, or turn it up to some high level like "WARN" or
    "ERROR", then you will see a pretty significant performance
    benefit, CPU usage down significantly, and network usage
    up significantly.

    2006-04-05 16:26:49 UTC by timiscool999