memcached counters missing in action

[Charlie Spurr]

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
>>>
>>>
>