IEP-14: Ignite failures handling (Discussion)

[yzhdanov]

Andrey Gura,

Why should we have any FailureHandler abstraction? We already have it -
this is EventListener. In my view it is better (and cleaner design) to add
events (similar to, for
example, org.apache.ignite.events.EventType#EVT_NODE_SEGMENTED) like
EVT_IGNITE_OOME, EVT_SYS_WORKER_FAILED and fire events accordingly to the
situation + execute configured system logic. We have exactly same way with
segmentation. We have policy which defines how system reacts and also allow
user to add event listeners.

For better understanding please take a look
at org.apache.ignite.plugin.segmentation.SegmentationPolicy
and org.apache.ignite.internal.managers.discovery.GridDiscoveryManager.DiscoveryWorker#onSegmentation.
Discovery manager records the event (allowing user to get notification on
it) and executes internal logic in case segmentation policy is not NOOP.

Thanks!

--Yakov

[dsetrakyan]

On Mon, Mar 19, 2018 at 2:24 PM, Yakov Zhdanov <[hidden email]> wrote:

> Andrey Gura,
>
> Why should we have any FailureHandler abstraction? We already have it -
> this is EventListener. In my view it is better (and cleaner design) to add
> events (similar to, for
> example, org.apache.ignite.events.EventType#EVT_NODE_SEGMENTED) like
> EVT_IGNITE_OOME, EVT_SYS_WORKER_FAILED and fire events accordingly to the
> situation + execute configured system logic. We have exactly same way with
> segmentation. We have policy which defines how system reacts and also allow
> user to add event listeners.
>

Yakov, how would it be possible to fire the events if Ignite is not in
operational state? For example, what can a user do if the Java application
ran out of memory?

[Yakov Zhdanov-2]

If java runs oome then you cannot guarantee anything. Including calling
runtime.halt().

My point is about consistent approach throughout the project. I think
developing new mechanism with separate interface is incorrect.

Yakov

[agura]

Yakov,

DiscoveryWorker is critical worker itself and could be terminated or
blocked by user provided listener. So specific abstraction for failure
handling is more robust way to solve the problem because it doesn't
dependent on other components.

On Tue, Mar 20, 2018 at 1:33 PM, Yakov Zhdanov <[hidden email]> wrote:
> If java runs oome then you cannot guarantee anything. Including calling
> runtime.halt().
>
> My point is about consistent approach throughout the project. I think
> developing new mechanism with separate interface is incorrect.
>
> Yakov

[yzhdanov]

Andrey, I understand your point but you are trying to build one more
mechanism and introduce abstractions that are already here. Again, please
take a look at segmentation policy and event types we already have.

Thanks!

Yakov

[Alexey Goncharuk]

Yakov,

I agree with Andrey that a separate abstraction for failure handling makes
sense.

First, using event listeners for this kind of response allows users to
install multiple listeners, which may be invoked in an unpredictable order,
this looks error-prone to me. Second, we may add an additional methods to
failure handlers in future releases (say, Ignite 3.00), so it is better to
have a separate interface right away.

I do not mind adding a separate event for this, though, but the event
should be used for notifications, not to run any reaction code.

--AG

2018-03-23 22:27 GMT+03:00 Yakov Zhdanov <[hidden email]>:

> Andrey, I understand your point but you are trying to build one more
> mechanism and introduce abstractions that are already here. Again, please
> take a look at segmentation policy and event types we already have.
>
> Thanks!
>
> Yakov
>