ATOMIC

ATOMIC provides cloud computing for python, js, cv, matlab, R, ... engines via the following web endpoints:

POST advance/step/insert a stateful engine
PUT	compile/init/update a stateful engine
DELETE deallocate/kill/delete a stateful engine
GET execute/read/select a stateless engines

Stateless engines are supported at the read (GET) endpoint, and are provided the following parameters:

TAU.i = {tau} = input event sinked to an engine
TAU.o = {tau} = output event sourced from an engine
TAU.p = {sql: {...}, query: {...} }

where the query hash will contain the supplied url parameters.

Stateful engines implement the step-init-kill (POST-PUT-DELETE) endpoints, and are supplied event tokens (tau):

TAU.i = [{tau}, ...] = events arriving to engine's input port
TAU.o = [{tau}, ...] = events departing from engine's output port
TAU.p = {port1: {...}, ... port2: {...}, ... sql: {...} }
TAU.port = engine's in/out port to step
TAU.thread = engine's 0-base thread counter

where input/output ports and engine code are defined by the engine context || COE || SBU.

An event token typically contain the following default fields (they can be freely interpretted and extended by the engine):

job = "" 	= Current job thread N.N...
work = 0 	= Anticipated/delivered data volume (dims bits etc)
disem = "" 	= Disemination channel for this event
classif = ""	= Classification of this event
cost = ""	= Billing center
policy = ""	= Data retention policy
status = 0	= Status code
value = 0	= Flow calculation

Manage

npm install @totemorg/atomic	# install
npm run start [ ? | $ | ...]	# Unit test
npm run verminor				# Roll minor version
npm run vermajor				# Roll major version
npm run redoc					# Regen documentation

Usage

Acquire and optionally configure ATOMIC like this:

var ATOMIC = require("atomic").config({
	key: value, 						// set key
	"key.key": value, 					// indexed set
	"key.key.": value					// indexed append
});

where configuration keys follow ENUMS deep copy conventions.

Program Reference

Constants

ATOMIC

Provides cloud computing on python, js, cv, matlab, R, ... engines via web endpoints. This module documented in accordance with jsdoc.

Requires: module:enums, module:child_process, module:fs, module:vm, module:pythonIF, module:opencvIF, module:RIF
Author: ACMESDS

### Env Dependencies

	HASGPU = 1|0
	HASCAFFE = 1|0
	ODBC_USER
	ODBC_PASS
	URL_MASTER  

• ATOMIC
  • .macs
  • .db
  • .lib
  • .init
  • .step
  • .config()
  • .run()
  • .save()
  • .insert(req, res)
  • .delete(req, res)
  • .select(req, res)
  • .update(req, res)
  • .mixContext()

ATOMIC.macs

Number of worker cores (aka threads) to provide in the cluster. 0 cores provides only the master.

Kind: static property of ATOMIC

ATOMIC.db

Next available core

Kind: static property of ATOMIC

ATOMIC.lib

Modules to share accross all I-engines

Kind: static property of ATOMIC

ATOMIC.init

Engine initializers.

Kind: static property of ATOMIC

ATOMIC.step

Engine steppers.

Kind: static property of ATOMIC

ATOMIC.config()

Configure the engine interface and estblish workers.

Kind: static method of ATOMIC

ATOMIC.run()

Run an engine.

Allocate the supplied callback cb(core) with the engine core that is/was allocated to a Client.Engine.Type.Instance
thread as defined by this request (in the req.body and req.log).  If a workflow Instance is
provided, then the engine is assumed to be in a workflow (thus the returned core will remain
on the same compile-step thread); otherwise, the engine is assumed to be standalone (thus forcing
the engine to re-compile each time it is stepped).

As used here (and elsewhere) the terms "process", "engine core", "safety core", and "worker" are 
equivalent, and should not be confused with a physical "cpu core".  Because heavyweight 
(spawned) workers run in their own V8 instance, these workers can tollerate all faults (even 
core-dump exceptions). The lightweight (cluster) workers used here, however, share the same V8 
instance.  Heavyweight workers thus provide greater safety for bound executables (like opencv and 
python) at the expense of greater cpu overhead.  

The goal of hyperthreading is to balance threads across cpu cores.  The workerless (master only)
configuration will intrinsically utilize only one of its underlying cpu cores (the OS remains, 
however, free to bounce between cpu cores via SMP).  A worker cluster, however, tends to 
balance threads across all cpu cores, especially when the number of allocated workers exceeds
the number of physical cpu cores.

Only the cluster master can see its workers; thus workers can not send work to other workers, only
the master can send work to workers.   

This method will callback cb(core) with the requested engine core; null if the core could not
be located or allocated.

Kind: static method of ATOMIC

ATOMIC.save()

Save context tau tokens into job files.

Kind: static method of ATOMIC

ATOMIC.insert(req, res)

Provides engine CRUD interface: step/insert/POST, compile/update/PUT, run/select/GET, and free/delete/DELETE.

Kind: static method of ATOMIC

| Param | Type | Description | | --- | --- | --- | | req | Object | Totem request | | res | function | Totem response |

ATOMIC.delete(req, res)

Provides engine CRUD interface: step/insert/POST, compile/update/PUT, run/select/GET, and free/delete/DELETE.

Kind: static method of ATOMIC

| Param | Type | Description | | --- | --- | --- | | req | Object | Totem request | | res | function | Totem response |

ATOMIC.select(req, res)

Provides engine CRUD interface: step/insert/POST, compile/update/PUT, run/select/GET, and free/delete/DELETE.

Kind: static method of ATOMIC

| Param | Type | Description | | --- | --- | --- | | req | Object | Totem request | | res | function | Totem response |

ATOMIC.update(req, res)

Provides engine CRUD interface: step/insert/POST, compile/update/PUT, run/select/GET, and free/delete/DELETE.

Kind: static method of ATOMIC

| Param | Type | Description | | --- | --- | --- | | req | Object | Totem request | | res | function | Totem response |

ATOMIC.mixContext()

Callback engine cb(ctx) with its state ctx primed with state from its ctx.Entry, then export its ctx state specified by its ctx.Exit. The ctx.sqls = {var:"query...", ...} || "query..." enumerates the engine's ctx.Entry (to import state into its ctx before the engine is run), and enumerates the engine's ctx.Exit (to export state from its ctx after the engine is run). If an sqls entry/exit exists, this will cause the ctx.req = [var, ...] list to be built to synchronously import/export the state into/from the engine's context.

Kind: static method of ATOMIC

paths

Paths to various things.

Kind: global constant

Contacting, Contributing, Following

Feel free to

• submit and status TOTEM issues
• contribute to TOTEM notebooks
• revise TOTEM requirements
• browse TOTEM holdings
• or follow TOTEM milestones

© 2012 ACMESDS