You are viewing a plain text version of this content. The canonical link for it is here.
Posted to issues@geode.apache.org by "ASF subversion and git services (Jira)" <ji...@apache.org> on 2022/06/06 23:46:00 UTC

[jira] [Commented] (GEODE-8977) Thread monitoring service should also show locked monitors and synchronizers

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

ASF subversion and git services commented on GEODE-8977:
--------------------------------------------------------

Commit 3df1e76ddbf2ab8f95e4b337b99b65117054af76 in geode's branch refs/heads/develop from Darrel Schneider
[ https://gitbox.apache.org/repos/asf?p=geode.git;h=3df1e76ddb ]

GEODE-8977: change ThreadMonitor to reduce how long it does a "stop the world" ThreadDump vm op (#7751)

Now uses a cheaper getThreadInfo that does not get lock info by default and calls getThreadInfo for each stuck thread. These are the defaults because they have the shortest time do the the VM ThreadDump operation.
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
>
>
> 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)