Work at SourceForge, help us to make it a better place! We have an immediate need for a Support Technician in our San Francisco or Denver office.

Close

Memcached 1.4.4 compatibility issue

Anonymous
2010-06-16
2013-04-17

  • Anonymous
    2010-06-16

    Looks like Memcached ClientLibrary has issues with Memcached 1.4.4 (and newer)

    Here's the error I'm getting:
    1.Error deleting key: XXXX@YYYY#121271.  Server response: CLIENT_ERROR bad command line format.  Usage: delete <key>

    From what I read in memcached release notes 1.4.4, looks like Memcached 1.2.x used to support so called lingering delete. This is when the client sends the delete command with an optional timeout parameter set to a non-zero value. This causes the server to flag the item as deleted but still keep in the cache (until the timeout expires) - this way the subsequent add operations would fail. This rather obscure feature was removed completely in 1.4.0, but 1.4.4 introduced a backwards compatibility change that allows the timeout value of 0 (i.e. non-lingering delete), while continuing to reject others.

    But why would Memcached ClientLibrary use the lingering delete feature?! Looking at the sources here's what I see:
    1.public bool Delete(string key)
    2.{
    3.    return this.Delete(key, null, DateTime.MaxValue);
    4.}

    Clearly the DateTime.MaxValue is a problem. Looking at http://sourceforge.net/projects/memcacheddotnet/ SVN I don't see this fixed yet. What is the procedure for submitting a patch or getting write access to memcacheddotnet repo?

     
  • Tim Gebhardt
    Tim Gebhardt
    2010-06-17

    Hi,

    If you send me a patch I'd be happy to look it over and incorporate it.

    Tim

     

  • Anonymous
    2010-06-18

    Actually, I just realized it might better be fixed in NHibernate.Caches.MemCache.MemCacheClient rather than in this client library.

    I thought NH wrapper calls the default method Delete(string key) which sends DateTime.MaxValue but it turns out DateTime.MaxValue is actually treated by the actual Delete method as a signal not to send any expiration date to memcached server. Which made me think the NH wrapper can't possibly be invoking  Delete(string key).

    Indeed, looking at NHibernate.Caches.MemCache.MemCacheClient's method Remove(object key) I see the following line:
       this.client.Delete(this.KeyAsString(key), DateTime.Now.AddSeconds((double) this.expiry));

    So rather than keeping NH wrapper supply an expiration date and making Memcached.ClientLibrary.MemcachedClient ignore, which is kinda silly, I think we should modify NHibernate.Caches.MemCache.MemCacheClient to not supply expiration date instead. Right?

     
  • Tim Gebhardt
    Tim Gebhardt
    2010-06-24

    If there's a problem with the NHibernate memcached L2 caching library I think you'd better talk to them.  I'm pretty sure that the code is based off of this library (the NH guys have emailed me one or two bugfixes in the past), but I think they forked the code to make it easier to incorporate changes to make integration and maintenance easier for them.  Which is fine, but this library hasn't really changed much for a long time (I consider it stable and "done" pending any newly discovered bugs), so this sounds like a new thing that they might have introduced.