[
https://issues.apache.org/jira/browse/GEODE-8977?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Darrel Schneider reopened GEODE-8977:
-------------------------------------
The fix for this needs to be reverted and improved. The fix calls
ThreadMXBean.getThreadInfo(long[] ids, boolean lockedMonitors, boolean
lockedSynchronizers) which on some jvms is stops all other threads from
running. This can cause the member to appear unresponsive and be forced out of
the geode cluster.
The fix can be improved by only calling getThreadInfo once with a list of all
the threads instead of calling it once per thread. Testing shows this prevents
the member from being unresponsive.
> Thread monitoring service should also show locked monitors and synchronizers
> ----------------------------------------------------------------------------
>
> Key: GEODE-8977
> URL: https://issues.apache.org/jira/browse/GEODE-8977
> Project: Geode
> Issue Type: Improvement
> Components: core
> Reporter: Darrel Schneider
> Assignee: Darrel Schneider
> Priority: Major
> Labels: GeodeOperationAPI, pull-request-available
> Fix For: 1.15.0
>
>
> The thread monitoring service shows the call stack of a hung thread but it
> does not show the synchronizations obtained by the frames in the call stack
> like a normal stack dump does.
> It looks like this is available from the ThreadInfo class that the service is
> already using by calling getLockedMonitors and getLockedSynchronizers. The
> getLockedMonitors returns a MonitorInfo which has information in it about
> which frame of the stack obtained it. MonitorInfo subclasses LockInfo which
> is what getLockedSynchronizers returns so it is possible that
> getLockedSynchronizers does not provide any additional information to be
> logged.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
