Check before running

Status

What other tools call it

Meridian's classification; an independent blind rating agreed on 86.2% of 312 rows (exact class, version 2).

Background

When to use it

In systems design, a fail-fast system immediately reports at its interface any condition that is likely to indicate a failure.^[4] Fail-fast systems are usually designed to stop normal operation rather than attempt to continue a possibly flawed process.^[4] A fail-fast system that is designed to halt as well as report the error on failure is less likely to erroneously perform an irreversible or costly operation.^[4] Finding the cause of a failure is easier in a fail-fast system, because the failure is reported with as much information as possible, as close to the time of failure as possible.^[4] Put a check before the first step that takes a long time or writes anything, so that an unreachable source stops the run before any half-finished output exists. (Meridian's view)

A failure can stay hidden until it is used: a system whose file-system path is wrongly set up, and not checked at startup, fails only later, when a client request arrives.^[4] Check the thing the next step will actually use, such as the URL it reads, the port it connects to or the database it queries, rather than only that the host is up. (Meridian's view)

In the Bruin CLI, a sensor asset waits until an external event has occurred, most commonly until data produced by an external system is available, before processing starts.^[5] By default a Bruin sensor gives up after 24 hours and the asset fails, and its timeout parameter can shorten that bound.^[5] Decide whether an unavailable source should stop the run at once or be waited for, and give any wait a limit, so a source that never arrives fails the run instead of holding it open. (Meridian's view)

The method

In computer programming, a precondition is a condition or predicate that must always be true just prior to the execution of some section of code.^[6] If a precondition is violated, the effect of the section of code becomes undefined and it may or may not carry out its intended work.^[6] Preconditions are sometimes tested using guards or assertions within the code itself.^[6]

Ping is a network management software utility used to test the reachability of a host on an Internet Protocol (IP) network.^[7] Pinging involves sending an Internet Control Message Protocol (ICMP) echo request to the target host and waiting for an ICMP echo reply.^[7] The ping utility was written by Mike Muuss in December 1983 during his employment at the Ballistic Research Laboratory, now the US Army Research Laboratory.^[7] Apache Hop's Ping a host action pings a host using the ICMP protocol, and its result is true when the host is reachable and false otherwise.^[8] In Apache Hop's Ping a host action, a classic ping calls the operating system's ping command and is true when no packets are lost.^[8] In Apache Hop's Ping a host action, a system ping uses Java methods and is true when the host name can be resolved and the host is reachable within the timeout.^[8]

Apache Hop's Telnet a host action tests a connection on a given port over the Telnet protocol, with port 23 and a timeout of 3000 milliseconds as its defaults.^[9]

Apache Hop's Check webservice availability action takes a connect timeout and a read timeout in milliseconds, whose values depend on the quality of service of the URL.^[1] When Apache Hop's Check webservice availability action fails, further information on the reason can be found in the log.^[1] Apache Hop's Check graph database connections action retrieves a small static value from each server to see whether it is properly up and running.^[10]

Bruin sensors work as a poking mechanism, checking the status of the external event every few minutes until it has occurred.^[5] A Bruin sensor's poke_interval parameter sets how often the poking occurs, in seconds.^[5] Bruin CLI runs sensors once by default, and its --sensor-mode flag can set them to skip or wait instead.^[5]

Compared with the alternatives

Apache Hop's Check If Webservice Is Available transform, unlike the workflow action, checks a URL field of the data stream for every row that comes in and returns a boolean result value.^[11][1] Use the per-row form to mark which of many URLs answer, and the workflow form to decide whether the run goes ahead at all. (Meridian's view)

A Bruin sensor can carry quality checks, which validate the external data once the sensor succeeds and before downstream assets run.^[5] A check before running asks whether a source can be reached; a quality check asks whether what arrived is right, and a pipeline that reads outside data is better for having both. (Meridian's view)

The error-handling policy of a fail-fast system is in some sense the opposite of a fault-tolerant system's, which has redundant components and moves computation requests to alive components when one fails.^[4]

Sources

1. [1]Check Webservice Availability | Apache Hopdocumentation
2. [2]Check Db connections | Apache Hopdocumentation
3. [3]tServerAlive component | Talend Components for Jobs Helpdocumentation
4. [4]Fail-fast system - Wikipediasecondary source
5. [5]Sensor Assets | Bruin CLIdocumentation
6. [6]Precondition - Wikipediasecondary source
7. [7]Ping (networking utility) - Wikipediasecondary source
8. [8]Ping a host | Apache Hopdocumentation
9. [9]Telnet a host | Apache Hopdocumentation
10. [10]Check graph database connections | Apache Hopdocumentation
11. [11]Check if webservice is available | Apache Hopdocumentation