Module: caf_ca/plug_ca_inqueue

A plug object that manages the input message queue for a CA.

Source:

Extends

Methods

getQueue() → {Object}

Gets the input message queue of this CA.

Source:
Returns:

The input message queue of this CA. This queue provides a length() method to find out the number of pending messages.

Type
Object

process(msg, cb)

Queues a message to be processed by this CA.

Errors during msg processing can come from:

1) An exception thrown during its processing. 2) An error argument returned in the call method callback 3) An error argument in any of the other callbacks in the pipeline.

The general strategy to deal with errors is as follows:

a) Try to roll back the transaction by doing abort b) If abort fails do a shutdown of the CA c) If shutdown fails exit node.js .

In terms of notifying the client we use the following strategy:

In case (1,a) treat it a system level error using exceptionThrown. We treat the same exceptions in the call method and in internal components. We want to encourage application/system code to not let propagate errors that way, and catch them and convert them to type 2). The carrot is that they get better reporting...

In case (2,a) treat it as an application level error (i.e., json_rpc.appReply), this means using a tuple (i.e., array) with error/data in the result field to encode node.js callback semantics.

In case (3,a) treat it as a system level error: For example, if any of the sub-systems returned an error in the prepare phase use a prepareFailure error.

In case (,b) return the error as in (,a) but log the cause of the CA shutdown.

In case (*, c) do nothing, just log and die.

A special case are commitFailure and checkpointFailure system errors since they cannot safely abort, they can only be recovered by CA shutdown.

Parameters:
Name Type Description
msg Object

A message to be processed.

cb cbType

A callback function to continue after processing the message and to propagate a response to the caller.

Source:

progress() → {boolean}

Checks for progress processing messages.

CAF detects hanged CAs and shuts them down.

Source:
See:
  • cron_ripper
Returns:

True if message queue is empty or at least one message was processed since the last call to progress.

Type
boolean