Versions Compared

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.


IDIEP-14
Author

Anton Vinogradov

Andrey Gura

Sponsor

Anton Vinogradov

DmitryAndrey Gura
CreatedFeb 20 2018
Status

Status
colour

Grey

Green
title

DRAFT

Done


Table of Contents

Motivation

Apache Ignite should have some general engine approach to handle critical failures.

Description

List of The following failures should be covered by this enginetreated as critical:

  • Persistence errors
  • IOOM errors (part of persistence errors?)
  • Critical workers crashes
  • Assertion errors
  • etc
  • System critical errors (e.g. OutOfMemoryError);
  • Unintentional system worker termination (e.g. due to an unhandled exception);
  • Cluster node segmentation.

User should have an ability to define node behavior in case of this failures.

System critical error - error which leads to the system's inoperability.

The following system critical errors should be handled with proposed approach:

  • File IO errors. Usually IOException's threw by read/write operations on file system. The following subsystems should be considered as critical:
    • WAL
    • Page store
    • Meta store
    • Binary meta store
  • IgniteOutOfMemoryException
  • OutOfMemoryError (we should have some memory reserved for this case at node startup to increase chances to handle OOM).

The following system workers are critical and ignite node will be inoperative in case of termination one of this workerList of system workers should be covered by this engine:

  • disco-event-workertcp-disco-sock-reader
  • tcp-disco-srvr
  • tcp-disco-msg-worker
  • tcp-comm-worker
  • grid-nio-worker-tcp-comm
  • exchange-worker
  • sys-stripe
  • grid-timeout-worker
  • db-checkpoint-thread
  • wal-file-archiver
  • wal-write-worker
  • wal-file-decompressor
  • ttl-cleanup-worker
  • nio-acceptor

Risks and Assumptions

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

Discussion Links

http://apache-ignite-developers.2346864.n4.nabble.com/Internal-problems-requiring-graceful-node-shutdown-reboot-etc-td24856.html

Reference Links

...



Important notes:

  • More than one Ignite node could be started in one JVM process.
  • Different nodes in one JVM process could belong to different clusters.

Initial design

IgniteConfiguration should be extended with methods:

Code Block
languagejava
public IgniteConfiguration setFailureHandler(FailureHandler hnd);

public FailureHandler getFailureHandler();

 

Where:

Code Block
languagejava
interface FailureHandler {
   boolean onFailure(Ignite ignite, FailureContext failureCtx);
}

class FailureContext {
   FailureType type;
   Throwable error;
}

enum FailureType {
   SEGMENTATION,
   SYSTEM_WORKER_TERMINATION,
   CRITICAL_ERROR
}

FailureHandler implementation will be able to handle Ignite critical failures accordingly to strategy provided by user.

The following implementations should be provided out of the box:

  • NoOpFailureHandler - Just ignores any failure. It's useful for tests and debugging.
  • RestartProcessFailureHandler - Specific implementation that could be used only with ignite.(sh|bat). Process must be terminated using Ignition.restart(true) call.
  • StopNodeFailureHandler - This implementation will stop Ignite node in case of critical error using Ignition.stop(true) or Ignition.stop(nodeName, true) call.
  • StopNodeOrHaltFailureHandler(boolean tryStop, long timeout) - This implementation will try to stop node if tryStop value is true. If node can't be stopped during provided timeout or tryStop value is false then JVM process will be terminated forcibly ( Runtime.halt() ).

Default failure handler is StopNodeOrHaltFailureProcessor where tryStop value is false.

Critical system worker must catch all exceptions ( Throwable and derived classes) in high-level try-catch block and take into account that thread could be terminated due to an programmatic mistake that leads to unintentional worker termination. So basic template should looks like the following code snippet:

 

Code Block
languagejava
@Override
public void run() {
    Throwable err = null;

	try {
      // Critical worker's code.
    }
    catch(Throwable e) {
      err = e;
    }
    finally {
      // Call failure handler.
      FailureContext failureCtx = new FaulureCtx(FailureType.SYSTEM_WORKER_TERMINATION, err);

      ctx.failure().process(failureCtx);  // Handle failure. Where ctx - kernal context.
    }
}

 

Example of using FailureHandler in IgniteConfiguration via Spring XML:

 

Code Block
languagexml
<bean class="org.apache.ignite.configuration.IgniteConfiguration">
    <property name="failureHandler">
        <bean class="org.apache.ignite.failure.StopNodeFailureHandler"/>
    </property>
</bean>

 

Risks and Assumptions

 

Discussion Links

  1. Internal problems requiring graceful node shutdown, reboot, etc.
  2. IEP-14: Ignite failures handling (Discussion)

Reference Links

  1. Apache Ignite documentation: Ignite life cycle
  2. Apache Ignite documentation: Start from command line

Tickets

Jira
serverASF JIRA
columnskey,summary,type,created,updated,due,assignee,reporter,priority,status,resolution
maximumIssues20
jqlQueryproject = Ignite AND labels IN (iep-14) ORDER BY status
serverId5aa69414-a9e9-3523-82ec-879b028fb15b