ignite-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Anton Vinogradov <avinogra...@gridgain.com>
Subject Re: Add emergency node closing handler to public Ignite API
Date Tue, 14 Nov 2017 16:46:11 GMT

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, but we
can handle some logical problems.


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>

> 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 are
> 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 should
> 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 Ignite
> > 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.
> >

  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message