[ 
https://issues.apache.org/jira/browse/GEODE-8977?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17550710#comment-17550710
 ] 

Darrel Schneider commented on GEODE-8977:
-----------------------------------------

We figured out that getThreadInfo is an expensive VM ThreadDump operation that 
on most JVMs is done in a global safepoint. This means that all other threads 
are paused (once each of them reaches a safepoint in their execution) and then 
the ThreadDump is done. This can cause what appears to be a gc stop the world 
collection.
To reduce the amount of time spend doing the ThreadDump operation, by default 
geode will not ask for lock/sync info but instead just get the stack trace. 
Also by default it will do the ThreadDump op on each stuck thread individually 
instead of with a single call that is passed all the thread ids. This reduces 
the amount of time spent in the op and on Java 15 and later it uses a 
thread-local safepoint instead of a global safepoint.

To get locks set the system property "gemfire.threadmonitor.showLocks" to 
"true".
To get ThreadInfo on all stuck threads with a single call set the system 
property "gemfire.threadmonitor.batchCalls" to "true".

> 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
>    Affects Versions: 1.15.0
>            Reporter: Darrel Schneider
>            Assignee: Darrel Schneider
>            Priority: Major
>              Labels: GeodeOperationAPI, blocks-1.15.0, pull-request-available
>             Fix For: 1.15.0, 1.16.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.20.7#820007)

Reply via email to