Download [#EHC-617] Ehcache 1.7.2 trips up Google App Engine restrictions

Survey
yes no Was this document useful for you?
   Thank you for your participation!

* Your assessment is very important for improving the workof artificial intelligence, which forms the content of this project

Document related concepts
no text concepts found
Transcript
[EHC-617] Ehcache 1.7.2 trips up Google App Engine restrictions Created:
01/Feb/10 Updated: 17/Jan/13 Resolved: 18/Jun/10
Status:
Project:
Component/s:
Affects
Version/s:
Fix Version/s:
Closed
Ehcache Core
None
1.7.2
Type:
Reporter:
Resolution:
Labels:
Remaining
Estimate:
Time Spent:
Original
Estimate:
Bug
Hung Huynh
Fixed
None
Not Specified
Issue Links:
Dependency
has a dependency EHC-718 ehcache-core-2.1.0 isn't compatible w... Closed
Terracotta
Target:
Fremantle
2.4.0
Priority:
Assignee:
Votes:
2 Major
Himadri Singh
0
Not Specified
Not Specified
Description
A newly added field in Element.java class upsets GAE:
private static final AtomicLongFieldUpdater<Element> HIT_COUNT_UPDATER =
AtomicLongFieldUpdater.newUpdater(Element.class, "hitCount");
Here's the stacktrace:
Caused by: java.lang.RuntimeException: java.security.AccessControlException: access denied
(java.lang.RuntimePermission accessDeclaredMembers)
at java.util.concurrent.atomic.AtomicLongFieldUpdater$CASUpdater.<init>(Unknown Source)
at java.util.concurrent.atomic.AtomicLongFieldUpdater.newUpdater(Unknown Source)
at net.sf.ehcache.Element.<clinit>(Element.java:56)
... 54 more
Caused by: java.security.AccessControlException: access denied (java.lang.RuntimePermission
accessDeclaredMembers)
at java.security.AccessControlContext.checkPermission(AccessControlContext.java:355)
at java.security.AccessController.checkPermission(AccessController.java:567)
at java.lang.SecurityManager.checkPermission(Unknown Source)
at java.lang.SecurityManager.checkMemberAccess(Unknown Source)
at java.lang.Class.checkMemberAccess(Unknown Source)
at java.lang.Class.getDeclaredField(Unknown Source)
Comments
Comment by Tim Eck [ 01/Feb/10 ]
Obviously we have no automated (or regularly run manual) testing of ehcache in GAE
Comment by gluck [ 11/Feb/10 ]
Steve
The GoogleAppEngine module which I was working on in October doesn't do anything useful
yet.
Ehcache-core can be tested in the meantime manually by our testers by creating a simple web
app in GAE and adding CacheManager.getInstance() to a JSP then hitting it and making sure it
does not explode.
The local test harness should give the same results but I have not gotten back to this.
This issue should be fixed for 2.0.
Greg
Comment by Chris Dennis [ 12/Feb/10 ]
The java.util.concurrent.atomic.AtomicLongFieldUpdater class that trips up GAE is on the class
white list (http://code.google.com/appengine/docs/java/jrewhitelist.html). So this seems to be a
GAE bug to me. Looking through the GAE issue tracker I found a couple of bugs that look
similar:
http://code.google.com/p/googleappengine/issues/detail?id=2042
http://code.google.com/p/googleappengine/issues/detail?id=2658
I've also found references to the sandbox in the production servers not being the same as the
sandbox in the local dev environment. In particular quite a few people have talked about code
that is loaded with a custom classloader not being granted the same permissions as code loaded
with the system classloader.
Comment by Chris Dennis [ 12/Feb/10 ]
I created a simple test in GAE that attempted to instantiate an AtomicLongFieldUpdater - this
works perfectly in the development sandbox that Google provide. However when uploaded to
the Google servers it triggered the same exception seen above. Since AtomicLongFieldUpdater
is supposed to be supported I have filed an issue with Google about this problem:
http://code.google.com/p/googleappengine/issues/detail?id=2769
Comment by Chris Dennis [ 12/Feb/10 ]
Pushing this out to Esperance while we wait for a response from Google. I see two possible
eventualities here:
1. Google fix the AtomicLongFieldUpdater and everything then works fine.
2. Google remove the AtomicLongFieldUpdater form the JDK white-list and we have to rework
this code (probably with an associated rise in heap usage)
Let wait and see what Google have to say on the matter first...
Comment by gluck [ 12/Apr/10 ]
Toby Reyelts has implemented a fix for GAE which will be out in late May/early June.
Comment by Chris Dennis [ 13/Apr/10 ]
Cool, thanks for expediting this Greg. When Toby closes the GAE issue, I'll close this.
Comment by Chris Dennis [ 17/Jun/10 ]
I'm punting this to pending until the underlying Google issue is closed. When that happens I will
resolve and assign this to the then current dev target.
Comment by Chris Dennis [ 18/Jun/10 ]
Underlying Google App Engine issue has been closed.
Comment by Tim Eck [ 18/Jun/10 ]
but have we verified anything on GAE?
Comment by Chris Dennis [ 18/Jun/10 ]
I'm was assuming (hoping) that some lovely person in QA would verify this in the GAE
production setup before closing this. I have a zipped GAE project attached to my Google issue
that should work correctly if they have fixed this in production.
Comment by Fiona OShea [ 18/Jun/10 ]
It will be tested by QA. thanks
Comment by Himadri Singh [ 05/Jul/10 ]
Cannot verify this bcoz of dependency JIRA.
Comment by Ludovic Orban [ 16/Sep/10 ]
I've implemented a workaround for the GAE bug as it apparently isn't yet fixed. It's in r2789.
Generated at Fri Apr 28 15:38:48 PDT 2017 using JIRA 6.2.4#6261sha1:4d2e6f6f26064845673c8e7ffe9b6b84b45a6e79.