[ https://issues.apache.org/jira/browse/GEODE-9471?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17524628#comment-17524628 ]
Darrel Schneider edited comment on GEODE-9471 at 4/28/22 7:37 PM: ------------------------------------------------------------------ For 1.15 the current implementation requires an add-opens of "java.lang" for the ThreadLocal class's privates. This open has been added see: GEODE-10263 was (Author: dschneider): For 1.15 the current implementation requires an add-opens of "java.lang" for the ThreadLocal class's privates. > gfsh show dead-locks will fail on java 16 and later > --------------------------------------------------- > > Key: GEODE-9471 > URL: https://issues.apache.org/jira/browse/GEODE-9471 > Project: Geode > Issue Type: Bug > Components: core > Reporter: Darrel Schneider > Priority: Major > Labels: Java16, Java17 > > The gfsh show dead-locks command ends up depending on this class: > org.apache.geode.distributed.internal.deadlock.UnsafeThreadLocal > Most of the time this UnsafeThreadLocal just behaves like a normal jdk > ThreadLocal (its super class). But when the gfsh command is executed it > causes "get" to be called on UnsafeThreadLocal. It uses a bunch of reflection > to prevent "get" from setting an initial value in the case of a miss. This > reflection calls setAccessible which will cause get to fail on java 16 and > later (see: > [https://softwaregarden.dev/en/posts/new-java/illegal-access-in-java-16]). > To workaround this failure set the JVM command line option: > --illegal-access=permit > The current solution adds get(Thread) to UnsafeThreadLocal which is different > than ThreadLocal.get(). To fix this we probably need to stop using > ThreadLocal and instead keep some kind of collection of the threads waiting > for a resource. It might also be possible to ask the resource what threads > are waiting for it. -- This message was sent by Atlassian Jira (v8.20.7#820007)