[
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)
