• Bug
  • Status: Closed
  • 2 Major
  • Resolution: Fixed
  • teck
  • Reporter: teck
  • April 27, 2011
  • 0
  • Watchers: 1
  • July 27, 2012
  • May 16, 2011


net.sf.ehcache.CacheException: java.io.IOException: Illegal string key: ￾¬ísrxrxp at org.terracotta.modules.ehcache.store.ValueModeHandlerSerialization.generateStringKeyFor(ValueModeHandlerSerialization.java:120) at org.terracotta.modules.ehcache.store.ValueModeHandlerSerialization.createPortableKey(ValueModeHandlerSerialization.java:55) at org.terracotta.modules.ehcache.store.ValueModeHandlerSoftLockAwareSerialization.createPortableKey(ValueModeHandlerSoftLockAwareSerialization.java:38) at org.terracotta.modules.ehcache.store.ClusteredStore.generatePortableKeyFor(ClusteredStore.java:641) at org.terracotta.modules.ehcache.store.ClusteredStore.doUnsafeGet(ClusteredStore.java:395) at org.terracotta.modules.ehcache.store.ClusteredStore.unsafeGetQuiet(ClusteredStore.java:386) at net.sf.ehcache.constructs.nonstop.store.LocalReadsOnTimeoutStore.getQuiet(LocalReadsOnTimeoutStore.java:93) at net.sf.ehcache.constructs.nonstop.store.ExecutorServiceStore.getQuiet(ExecutorServiceStore.java:366) at net.sf.ehcache.constructs.nonstop.store.NonstopStoreImpl.getQuiet(NonstopStoreImpl.java:342) at net.sf.ehcache.Cache.searchInStoreWithoutStats(Cache.java:1925) at net.sf.ehcache.Cache.getQuiet(Cache.java:1788) at net.sf.ehcache.Cache.getKeysWithExpiryCheck(Cache.java:1836)

With local reads getKeys() turns into a getLocalKeys() call on the clustered store. getLocalKeys() does not deserialize the keys like it should (see CDV-1444).

I think the fix here is to make sure we deserialize the local keys but that implies making sure no remote resources (like faulting an object) are required. In particular I think we’d need to make sure the map in object stream class serializer in non-partial to make such a guarantee


Fiona OShea 2011-05-03

Are you already working on this?

jawaid hakim 2011-05-10

What is the workaround?

Tim Eck 2011-05-10

Sorry the “severity” rating on this one is misleading. There isn’t really a workaround short of avoiding this code path or not using local-reads timeout behavior.

jawaid hakim 2011-05-10

I imagine there are lots of applications out there that are relying on non-stop caches and calling getKeys(). Our own platform is used for bond trading by multiple banks - cache outage is not an option and all caches are non-stop. So we are in a tough spot.

Please tell me there is another workaround!

Tim Eck 2011-05-10

This bug does not exist in 2.3.x versions of ehcache I believe. Unfortunately I don’t think there is a workaround until there is a fix

If you have a paid support contract there might be other options available to you but I wouldn’t be the one to guide in that area

jawaid hakim 2011-05-11

We are using Ehcache 2.4.2 with TC 2.5.1

Tim Eck 2011-05-16

local key retrieval should now be functional in trunk

Tim Eck 2011-05-18

If anyone affected by this issue would care to test this you can download a trunk nightly terracotta distribution .


Any feedback is appreciated.