...

• Persistence errors
• IOOM errors (part of persistence errors?)
• IO errors (list to be provided)
• OOM (we should have some memory reserved for this case at node startup to increase chances to handle OOM)
• Assertion errors (we should handle assertions as failures in case -ea flag set) (should be covered at Throwable catch for every system worker as well)

Initial design

IgniteConfiguration have to be extended with methods

IgniteConfiguration setIgniteFailureHandler(IgniteFailureHandler igniteFailureHnd)
IgniteFailureHandler getIgniteFailureHandler()

Where

interface IgniteFailureHandler {
   IgniteFailureAction onFailure(IgniteFailureContext failureCtx);
}

class IgniteFailureContext {
   IgniteFailureType type;
   Throwable cause;
}

enum IgniteFailureAction {
   RESTART_JVM,
   STOP,
   NOOP;
}

enum IgniteFailureType {
   SEGMENTATION,
   SYSTEM_WORKER_CRASHED,
   CRITICAL_ERROR
}

So, provided by user subclass of IgniteFailureHandler able to decide what to do (see. IgniteFailureAction) on each registered failure (see. IgniteFailureContext).

Risks and Assumptions

// Describe project risks, such as API or binary compatibility issues, major protocol changes, etc.

...