[
https://issues.apache.org/jira/browse/IGNITE-6171?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16255304#comment-16255304
]
Vladimir Ozerov edited comment on IGNITE-6171 at 11/16/17 1:30 PM:
-------------------------------------------------------------------
[~cyberdemon], the very problem with this approach is that we observe GC pause
_after_ it is finished. This is fine to log max GC pause somewhere and show a
kind of "red flag" to the user. But we cannot react to this pause anyhow. To
the constrast, solution with native threads will allow to shutdown unresponsive
node _during_ GC pause. This was the original idea.
But the question is - does original idea makes sense? Do we really want to
shutdown the node due to long GC pause? This needs to be discussed separately.
was (Author: vozerov):
[~cyberdemon], the very problem with this approach is that we observe GC pause
_after_ it finished. This is fine to log max GC pause somewhere and show a kind
of "red flag" to the user. But we cannot react to this pause anyhow. To the
constrast, solution with native threads will allow to shutdown unresponsive
node _during_ GC pause. This was the original idea.
But the question is - does original idea makes sense? Do we really want to
shutdown the node due to long GC pause? This needs to be discussed separately.
> 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)
