Memcached bucket not expiring via spymemcached client

I’m currently running tests against our Couchbase Server 3.0.1 using a spymemcached(2.11.7) Java client that’s packaged with Simple Spring Memcached 3.6.0 library. I’m able to store, retrieve and delete key/values stored in the memcached buckets, however in our live roll out we would expect the expirations set on the keys to automatically expire rather than being explicitly deleted. I’m currently setting an expiry of 300ms through Simple Spring Memcached annotation on a key/value storing method like this for instance,

@UpdateSingleCache(namespace = someNameSpace, expiration = 300)
public void storeTheKey(@ParameterValueKeyProvider String thisKey, @ParameterDataUpdateContent SomeResult storedResult)
//log some stuff

So this method does store “thisKey” and “storedResult”, however after the expired time I’m still seeing the key/value in the memcached bucket of the server node.

Anybody familiar with using Simple Spring Memcached via Spymemcached with Couchbase out there? Or perhaps there’s a default expiry that could be set explicitly on the Couchbase Server to handle this?


Is the document also available through a subsequent get over spring? The UI can have some delay but the actual operations should be strongly consistent.

HI Dashl,

Yes, subsequent call to get the value is successful in my test. But even after 24 hr period I still see the server node that stored the memcached key still contain the same item count.


@calvin can you precise your last comment a little bit?

When you say its successful are you saying it is properly deleted (so the get returns null)? And when you see you see the item count, how do you check that count?

@daschl Yes, so after deleting it, I’d get a null value returned. I’m logging in directly to the Couchbase Console, under “Server Nodes”, I have 3, there’s a column Items(Active/Replica), I see this,

It’s been like this for at least a week now. Any ideas @daschl ?

Moving my question over to the Couchbase Server side to hopefully elicit more reponses from a broader audience. Thanks!