Mailing-List: contact dev-help@ignite.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@ignite.apache.org
MIME-Version: 1.0
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>
In-Reply-To: <CAGt6o8nwu0=J4mS5XgEjmObzYkVFFU66MZu1wAKuDL+FkWMddg@mail.gmail.com>
From: Anton Vinogradov <avinogradov@gridgain.com>
Date: Tue, 14 Nov 2017 18:05:49 +0000
Message-ID: <CAOKDqC9LqE9Mj_8LCAgrSWjtcC5-Y-MgMmkfCceNF-wX+mr+KA@mail.gmail.com>
Subject: Re: Add emergency node closing handler to public Ignite API
To: dev@ignite.apache.org
Content-Type: multipart/alternative; boundary="f403045f7ca845f4a3055df53d38"
archived-at: Tue, 14 Nov 2017 18:06:06 -0000

--f403045f7ca845f4a3055df53d38
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

Vova,

We should provide user ability to be notified in case some node decided to
stop itself.
Only user know how he want to be notified, so we should provide ability to
register custom callback(eg. send sms or call rest service)
This will cover cases when node stops gracefuly.

Please, see Semen's comment at
https://issues.apache.org/jira/browse/IGNITE-5811 for details.

P.s. Cases when node stops without ability to do something should be
covered by external watchdog.

=D0=92=D1=82, 14 =D0=BD=D0=BE=D1=8F=D0=B1. 2017 =D0=B3. =D0=B2 20:08, Vladi=
mir Ozerov <vozerov@gridgain.com>:

> Can you explain what kind of logic could be placed there? And why do we
> need another configuration property and/or interface? We already have
> LifecycleBean, where Ignite instance could be injected, so user is alread=
y
> able to perform anything there.
>
> On Tue, Nov 14, 2017 at 7:46 PM, Anton Vinogradov <
> avinogradov@gridgain.com>
> wrote:
>
> > Vova,
> >
> > That's not about "kill -9" or OOM, that's about case when node detected
> > something and decided to stop itself (eg. persistence errors,
> > IgniteOutOfMemoryException, ExchangeWorker died)
> > Sure, we can't handle OOM or 100% CPU utilization by GC it that way, bu=
t
> we
> > can handle some logical problems.
> >
> > Andrey,
> >
> > I propose to refactor method to ignite.onClose(SomeClosure<SomeReason>)
> > In this case user will be able to register callback on all graceful
> stops,
> > and
> > detect it's reason.
> >
> >
> > On Tue, Nov 14, 2017 at 7:29 PM, Vladimir Ozerov <vozerov@gridgain.com>
> > wrote:
> >
> > > I am not sure this makes sense. First, in general case we do not have
> > > access to Java. E.g. in case of very long GC pause all Java threads a=
re
> > > stuck and it is impossible to invoke anything. Second, some other
> > > conditions may be unrecoverable, such as OOME, where there is no
> > guarantee
> > > that any operation succeed. So this is not graceful shutdown. We shou=
ld
> > > kill the node forcefully IMO.
> > >
> > > On Tue, Nov 14, 2017 at 7:23 PM, Andrey Kuznetsov <stkuzma@gmail.com>
> > > wrote:
> > >
> > > > Hi Igniters!
> > > >
> > > > When some node detects critical error, e.g. OOME, deadlock, etc, it
> > > should
> > > > invoke some user-defined callback and then attempt to close itself
> > > > gracefully. In order to make this possible we need to enhance Ignit=
e
> > > > interface by adding something like Ignite.onEmergencyClose(
> > SomeClosure).
> > > >
> > > > First, I'd like to get your feedback on this potential change. Then
> we
> > > can
> > > > refine SomeClosure structure.
> > > >
> > > > --
> > > > Best regards,
> > > >   Andrey Kuznetsov.
> > > >
> > >
> >
>

--f403045f7ca845f4a3055df53d38--