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 <avinogra...@gridgain.com> wrote: > Vova, > > Could you point to metric you're talking about? > > On Wed, Nov 15, 2017 at 1:06 PM, Andrey Kuznetsov <stku...@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 <voze...@gridgain.com>: > > > > > > This information should be available through local metrics, so that it > is > > > accessible from Ignite instance. > > > > > >
