memcached counters missing in action

[Greg Whalin]

He is referring to using incr and decr which are most definitely part of
the memcached api and not *just* a client abstraction.  The
storeCounter() and getCounter() methods in the java client are basically
just wrappers to set() and get() which do not (de)serialize the int
object on the way in/out of the cache.  This is done so that incr and
decr work correctly on the object in cache.

That said, it sounds like an exception is being thrown when the
getCounter() method is trying to create a Long object from the value in
the cache (crappy error messaging on my part).  It would be useful to
see what is actually in the cache at that time.  Charlie, when you see
this again, please telnet into your memcached server and issue a "get
key" command and let me know what you find.  Also, to answer your questions:

1) the storeCounter() method does not set an expiration, however, the
storeCounter() method is basically just a wrapper for set(), so an
expiration could most definitely be set.  Also, just because an
expiration is not set does not mean that the object will live in cache
permanently.  If the cache fills up, it is entirely possible your
counter could be pushed out of cache.

2) if you want to enforce an expiration time, then yes, you need to use
set().  However, you need to make sure that you do so in a way that does
not serialize the object.  This is currently not available in the public
API (there is a private method which allows this).  If you really
want/need an expiration set on a counter, please let me know and I will
add it to the queue of improvements to the client.

3) nope ... instead I should fix the stupid error message in
getCounter() that says the object is not in cache and instead error
correctly "Exception thrown while trying to create Long() on data: %s"

Hope this helps.

Greg

Brad Fitzpatrick wrote:
> What's a counter?
> 
> memcached has no such object.
> 
> I assume the Java client gives you such an abstraction.  In any case,
> they're not magic.  They die like the rest.
> 
> - Brad
> 
> 
> On Fri, 24 Mar 2006, Charlie Spurr wrote:
> 
>> I'm using memcached counters to track budget balances and
>> I'm seeing some of the counters mysteriously disappear
>> from the cache sometime after a decr of the counter.
>>
>> Here's what I'm doing for each counter:
>> a) At application startup on the primary app server, I
>>     load the current remaining balance for each budget
>>     from a MySQL database into a memcached counter using
>>     the Java MemCachedClient's storeCounter(String key,
>>     long value) method.
>>
>> b) As billable events occur asynchronously, I call the client's
>>     decr(String key, long amount) method to decrement the
>>     remaining balance in the cache.
>>
>> c) In a synchronization thread (one per app server, ten total),
>>     I call the MemCachedClient's getCounter(String key) method
>>     to retrieve the cached budget balance and sync it back to
>>     the database.
>>
>> This seems to run fine for a while until getCounter or decr calls
>> start to hit "MemCached.MemCachedClient - counter not found at key:"
>> errors. When this occurs, MemCachedClient's keyExists(String key)
>> calls return true but getCounter or decr calls fail with this error.
>>
>> My questions are:
>> 1) Do counters expire like Object data expire or are they expected
>>     to remain in the cache until they are deleted or flushed?
>>
>> 2) If counters expire, how do I set their expiration time? There is no
>>     version of MemCachedClient's storeCounter that takes a expire Date
>>     parameter. Should I be using MemCachedClient's  set(String key,
>>     Object value, Date expiry) instead of (or in combination with)
>>     storeCounter?
>>
>> 3) Shouldn't MemCachedClient's keyExists(String key) return false
>>     when calls to getCounter or decr calls fail with "counter not
>>     found at key:" errors?
>>
>> Charlie Spurr
>> Kayak.com
>>
>>