[ https://issues.apache.org/jira/browse/GEODE-9471?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Darrel Schneider updated GEODE-9471: ------------------------------------ Description: 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. was: 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 iterates all the threads in the jvm checking which are in the thread local by doing a get. This would cause the thread local to end up containing all threads. What we could do on these scans (they only happen when gfsh show dead-locks is executed) is if the get misses for a thread we could turn around and call ThreadLocal.remove. A bit more expensive than the current solution but it would be safe and work on java 16. > 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 > > 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.3.4#803005)