Dmitriy, > Sleeping Java Thread IMO is not an option, because thread can be in > Timed_Watiting logner than timeout.
That's the only one idea we have, and, according to tests, it works! > Did I understand correctly that the native stream is proposed? And our goal > now is to select best framework for this? That's one of possible cases. We can replace native thread by another JVM, this should solve compatibility issues. On Mon, Nov 20, 2017 at 4:24 PM, Dmitry Pavlov <dpavlov....@gmail.com> wrote: > Sleeping Java Thread IMO is not an option, because thread can be in > Timed_Watiting logner than timeout. > > Did I understand correctly that the native stream is proposed? And our goal > now is to select best framework for this? > > Can we limit this oppotunity with several popular OS (Win,Linux), and do > not implement this feature for all operation systems? > > > пн, 20 нояб. 2017 г. в 14:55, Anton Vinogradov <avinogra...@gridgain.com>: > > > Igniters, > > > > Since no one rejected proposal, let's start from part one. > > > > > I propose to add a special thread that will record current time every N > > > milliseconds and check the difference with the latest recorded value. > > > The maximum and total pause values for a certain period can be > published > > in > > > the special metrics available through JMX. > > > > On Fri, Nov 17, 2017 at 4:08 PM, Dmitriy_Sorokin < > > sbt.sorokin....@gmail.com> > > wrote: > > > > > Hi, Igniters! > > > > > > This discussion thread related to > > > https://issues.apache.org/jira/browse/IGNITE-6171. > > > > > > Currently there are no JVM performance monitoring tools in AI, for > > example > > > the impact of GC (eg STW) on the operation of the node. I think we > should > > > add this functionality. > > > > > > 1) It is useful to know that STW duration increased or any other > > situations > > > leads to similar consequences. > > > This will allow system administrators to solve issues prior they become > > > problems. > > > > > > I propose to add a special thread that will record current time every N > > > milliseconds and check the difference with the latest recorded value. > > > The maximum and total pause values for a certain period can be > published > > in > > > the special metrics available through JMX. > > > > > > 2) If the pause reaches a critical value, we need to stop the node, > > without > > > waiting for end of the pause. > > > > > > The thread (from the first part of the proposed solution) is able to > > > estimate the pause duration, but only after its completion. > > > So, we need an external thread (in another JVM or native) that is able > to > > > recognize that the pause duration has passed the critical mark. > > > > > > We can estimate (STW or similar) pause duration by > > > a) reading value updated by the first thread, somehow (eg via JMX, > shmem > > > or > > > shared file) > > > or > > > b) by using JVM diagnostic tools. Does anybody know crossplatform > > > solutions? > > > > > > Feel free to suggest ideas or tips, especially about second part of > > > proposal. > > > > > > Thoughts? > > > > > > > > > > > > -- > > > Sent from: http://apache-ignite-developers.2346864.n4.nabble.com/ > > > > > >
