ignite-issues mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "ASF GitHub Bot (JIRA)" <j...@apache.org>
Subject [jira] [Commented] (IGNITE-6171) Native facility to control excessive GC pauses
Date Tue, 21 Nov 2017 13:42:01 GMT

    [ https://issues.apache.org/jira/browse/IGNITE-6171?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16260739#comment-16260739

ASF GitHub Bot commented on IGNITE-6171:

GitHub user x-kreator opened a pull request:


    IGNITE-6171: + LongJVMPauseDetector, + longJVMPausesCount and longJVM…

    …PausesTotalDuration properties of IgniteMXBean.

You can merge this pull request into a Git repository by running:

    $ git pull https://github.com/x-kreator/ignite ignite-6171

Alternatively you can review and apply these changes as the patch at:


To close this pull request, make a commit to your master/trunk branch
with (at least) the following in the commit message:

    This closes #3076
commit 37283985ff4a52d28691762fec1e99cc828ec762
Author: Unknown <cyberdemon@bk.ru>
Date:   2017-11-21T13:38:29Z

    IGNITE-6171: + LongJVMPauseDetector, + longJVMPausesCount and longJVMPausesTotalDuration
properties of IgniteMXBean.


> Native facility to control excessive GC pauses
> ----------------------------------------------
>                 Key: IGNITE-6171
>                 URL: https://issues.apache.org/jira/browse/IGNITE-6171
>             Project: Ignite
>          Issue Type: Task
>          Components: general
>            Reporter: Vladimir Ozerov
>            Assignee: Dmitriy Sorokin
>              Labels: iep-7, usability
> Ignite is Java-based application. If node experiences long GC pauses it may negatively
affect other nodes. We need to find a way to detect long GC pauses within the process and
trigger some actions in response, e.g. node stop. 
> This is a kind of Inception \[1\], when you need to understand that you sleep while sleeping.
As all Java threads are blocked on safepoint, we cannot use Java's thread to detect Java's
GC. Native threads should be used instead.
> Proposed solution:
> 1) Thread 1 should periodically call dummy JNI method returning current time, and set
this time to shared variable;
> 2) Thread 2 should periodically check that variable. If it has not been changed for some
time - most likely we are in GC pause. Once certain threashold is reached - trigger compensating
action, whether this is a warning, process kill, or what so ever.
> Justification: crossing native -> Java boundaries involves safepoints. This way Thread
1 will be trapped if STW pause is in progress. Java method cannot be empty, as JVM is smart
enough and can deduce it to no-op. 
> \[1\] http://www.imdb.com/title/tt1375666/

This message was sent by Atlassian JIRA

View raw message