memcached counters missing in action

[Greg Whalin]

Nope, that won't work.  That will store a serialized Long(1000) object
to the cache.  Calling incr() or decr() on it will reset it to 0
(according to the api docs).

Charlie Spurr wrote:
> Greg,
> Yes, I would like to set an expiration time on counters so
> please add that to the queue for improvements for the Java
> client.
> 
> In the meantime, would this work...
> Long balance = new Long(10000);
> MemCachedClient = MemCachedClient();
> client.set("Balance1", balance, expireDate);
> client.decr("Balance1", 50);
> client.getCounter("Balance1");
> 
> or would I have to use (Long)client.get("Balance1");
> instead of getCounter?
> 
> _Charlie
> 
> 
> On Mar 24, 2006, at 2:41 PM, Greg Whalin wrote:
> 
>> 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
>>>>
>>>>
>>
>