caf_ca/plug_ca_inqueue

Gets the input message queue of this CA.

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.

Checks for progress processing messages.

CAF detects hanged CAs and shuts them down.