Mailing-List: contact dev-help@ignite.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@ignite.apache.org
MIME-Version: 1.0
In-Reply-To: <CAOKDqC8Gf5E9LkiiLHd4xX0RBvi8pkBUZpYR7d=_t=XJBkaONA@mail.gmail.com>
References: <CA+Bp9OD2cuYk1MBu_P=SN_U6psc8u5VcEfj68LQE8d5QOG3+ow@mail.gmail.com>
 <CAGt6o8mqFfR0TdUXgxuiD+J_fEEE932grZ_ryhtOjnC1nY3wgg@mail.gmail.com>
 <CAOKDqC8nBKFXmPyLFSb93+BGzU5pQEFFF1+dHKY1ZwAaLbrSpw@mail.gmail.com>
 <CAGt6o8nwu0=J4mS5XgEjmObzYkVFFU66MZu1wAKuDL+FkWMddg@mail.gmail.com>
 <CAOKDqC9LqE9Mj_8LCAgrSWjtcC5-Y-MgMmkfCceNF-wX+mr+KA@mail.gmail.com>
 <CABuYRcrPd5QSHB-OniuZodKAwe_gjq8kkWa70NLOEmwJm4JzHA@mail.gmail.com>
 <CA+Bp9OAX6r_AUNM4XoOFtSYDQ0MO8y=g0+ttAXGB--hiPMRQcg@mail.gmail.com>
 <CAGt6o8nN9x8_s1J_PNsOoczmJAjAd76HkvCr_7mN_XtR4=bRDQ@mail.gmail.com>
 <CA+Bp9OB+EkiDRa7ZfZGz+jPkaxUbNHU6Vavid24vdcUsyBsn6g@mail.gmail.com>
 <CABuYRcrbQNZ0N4QhVBup98gBh1wOkBni3-X3KsYgWo2W8YEM1A@mail.gmail.com>
 <CAGt6o8mjx+erqy2Rvjh1GXxBbKMD9WwdkTXESaogSk=hN8ykpA@mail.gmail.com>
 <CA+Bp9ODVycSu950=iq3DDHkU+nw+Pq=E+sfOYNC82sJ=K9_uxQ@mail.gmail.com> <CAOKDqC8Gf5E9LkiiLHd4xX0RBvi8pkBUZpYR7d=_t=XJBkaONA@mail.gmail.com>
From: Vladimir Ozerov <vozerov@gridgain.com>
Date: Wed, 15 Nov 2017 13:34:34 +0300
Message-ID: <CAGt6o8kzfvrqnW8wpk-wmL3wUvyTn2ZLKOOM8bGt-3xQLL+8Ag@mail.gmail.com>
Subject: Re: Add emergency node closing handler to public Ignite API
To: dev@ignite.apache.org
Content-Type: multipart/alternative; boundary="f403043c4668b846f7055e030ca6"
archived-at: Wed, 15 Nov 2017 10:34:39 -0000

--f403043c4668b846f7055e030ca6
Content-Type: text/plain; charset="UTF-8"

AFAIK the idea was not only to shutdown the node, but also to give user
(e.g. administrator) ability to observe the problem from the outside, e.g.
through JMX. E.g. if we detect Java-level deadlock, it doesn't mean that
the only possible solution is node shutdown. In addition it could be no-op,
e.g. to give user chance to collect additional system info, or simply
because this particular deadlock is resolvable (e.g.
Lock.lockInterruptibly()). So as we need to expose health info through JMX
anyway, we could also give user programmatic access to it as well.
Alternatively, we can expose this info through JMX only and ask user to get
instance of that bean manually.

On Wed, Nov 15, 2017 at 1:19 PM, Anton Vinogradov <avinogradov@gridgain.com>
wrote:

> Vova,
>
> Could you point to metric you're talking about?
>
> On Wed, Nov 15, 2017 at 1:06 PM, Andrey Kuznetsov <stkuzma@gmail.com>
> wrote:
>
> > Vladimir,
> >
> > Could you please refine, what are local metrics? Should I extend Ignite
> > interface by adding something similar to dataRegionMetrics() or there is
> > some universal mechanism to handle metrics?
> >
> > 2017-11-15 8:30 GMT+03:00 Vladimir Ozerov <vozerov@gridgain.com>:
> > >
> > > This information should be available through local metrics, so that it
> is
> > > accessible from Ignite instance.
> > >
> >
>

--f403043c4668b846f7055e030ca6--