[
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:
https://github.com/apache/ignite/pull/3076
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:
https://github.com/apache/ignite/pull/3076.patch
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 <[email protected]>
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
(v6.4.14#64029)
