-1

For a number of java services we're using AWS ElastiCache as a distributed cache integrated by Spring Cache abstraction and spymemcached.

In one service I see the behaviour that i get a diffent type of result than I expect, leading to a ClassCastException. To be precise: I have a cache key and as a result I expect a List, but instead i get a result of Type2.

We have defined a number of caches, some of the use the same cache key:

Cache1:
cacheKey -> List<Type1>

Cache2:
cacheKey -> Type2

Since they are in different caches, this works when we use a simple hashmap based cache. With ElastiCache/Memcached however it seems we don't really have different caches (which would make sense from what I know of memcached - which is not much).

I would have expected spymemcached to take care of this by manipulating cache keys so the application wouldnt need to be aware of the actual cache implementation (This could be done by manipulating cache keys and prefixing them with the cache name i.e.).

From a few debugging sessions and the errors that I see, this doesn't seem to be the case.

I've specifically looked at this class:

com.google.code.ssm.spring.SSMCache

L82:  value = cache.get(getKey(key), null);
L154: private String getKey(final Object key) {
L155:    return key.toString();
L156: }

I would have expected to have the getKey() method to prefix with a cache name.

So my questions are:

  1. Do I understand correctly what is going on here?
  2. Is there maybe something that can be configured with spymemcached to make it behave in the expected way?

Also, any other thoughts are appriciated! Thanks!

  • What is `Type2` that you get back and how does it relate to original `Type1` and `List`? What are (the implementations of) `Cache1` and `Cache2` and what is their setup? – Germann Arlington Mar 24 '14 at 11:42
  • Type1 and Type 2 are just POJOs and they have no direct relation. The configurations are minimal (some expiry time)... –  Mar 24 '14 at 11:45
  • To me it says that something is storing different (type) data using the same keys. That is an incorrect usage of distributed cache. – Germann Arlington Mar 24 '14 at 11:51
  • Well, we are using a number of caches, and i would expect that cache keys of one cache should not influence cache keys of another. Spring and spymemcached should take care of this, the application should just work as before, in my opinion... –  Mar 24 '14 at 11:53
  • How do you expect the distributed cache (interface that should be handling all your requests) to handle requests to get something via the key if that key is not unique between all instances of cache servers? If you use `put(key, data, dataType)` to allow the cache to decide where to store the object then you should have similar `get(key, dataType)` to allow the same decision to take place. I would expect `get(key)` to return first available instance of data – Germann Arlington Mar 24 '14 at 12:05

1 Answers1

1

Ok, i found this is an issue with version 3.2.0 of simple-spring-memcached. Version 3.3.0 fixes it.