• Bug
  • Status: Closed
  • 2 Major
  • Resolution: Fixed
  • ehcache-web
  • hsingh
  • Reporter: teck
  • May 12, 2010
  • 0
  • Watchers: 0
  • January 17, 2013
  • May 21, 2010




Comment from Chris: unless GAE have modded
the Java security model around this you can’t grant permission to
rename a thread without also granting most other thread modification
perms (e.g. Thread.stop()). They are almost certainly not going to
change this.

Likely we need to do something in the ehcache code to avoid this – *AND* expand GAE testing to include ehcache-web and other non-core modules.


Hung Huynh 2010-05-12

The Thread.setName() is used to avoid a reentrant in order to avoid a deadlock on BlockingCache. Maybe a ThreadLocal variable could be used instead

Tim Eck 2010-05-12

I don’t understand your comment. I can’t possible imagine how setting a thread name would avoid a deadlock. Do you mean setDaemon() or something else?

Tim Eck 2010-05-12

reading the code a little now I can see that the current Thread’s name is being hijacked/decorated to detect reentering. I agree that a ThreadLocal would be vastly more appropriate for doing that. I assume a ThreadLocal would work in GAE but we don’t know until we test it.

Hung Huynh 2010-05-21

To verify this issue:

  1. Download and unzip GAE SDK http://googleappengine.googlecode.com/files/appengine-java-sdk-1.3.4.zip
  2. Download and unzip attachment from this jira servicecache.zip
  3. From GAE uninstall folder, run:

bin/dev_appserver.sh /path/to/unzipped/servicecache

  1. Hit http://localhost:8080
  2. Click around the links, you should not get any error. The cache TTL is 5s so after 5s, refresh a link will give you new content

If you test this servicecache example with an old ehcache-web-2.0.2-SNAPSHOT (or maybe ehcache-web-2.0.1), you’ll get error (do this by copy new ehcache-web jar into servicecache/WEB-INF/lib)

Himadri Singh 2010-07-13

To test this need EHC-718 fixed.