Persistent Correspondents

We introduced the concept of persistent correspondents in the section CM Correspondent Name. A reusable name and a file-based ledger allow a persistent correspondent to continue certified delivery beyond the invalidation of a CM transport or the restart of a process.

Example

Consider an example application system, in which program JOE generates important information, and sends it to program SUE in certified messages on the subject REMEMBER.THIS. Upon receipt, SUE stores the information in a database.

If either JOE or SUE terminate unexpectedly, it is crucial that certified messages still arrive for entry into the database. To ensure this result, both programs must represent persistent correspondents—that is, both programs create CM transports with reusable names (JOE_PER and SUE_PER), and each of these CM transports keeps a file-based ledger. In addition, SUE requires old messages by setting a parameter when creating the CM transport SUE_PER.

During operation, JOE has sent message number 57 on the subject REMEMBER.THIS, but has not yet received delivery confirmation for messages 53–56. SUE is processing message 53, when a sudden hardware failure causes SUE to terminate. Meanwhile, JOE continues to send messages 58–77.

When the computer restarts, SUE restarts and recreates SUE_PER. The ledger file for SUE_PER indicates that message 52 was received and confirmed for the subject REMEMBER.THIS. As soon as SUE_PER discovers that JOE_PER sends labeled messages on the required subject, SUE_PER requests a certified delivery agreement for the subject REMEMBER.THIS. When JOE_PER accepts, JOE_PER retransmits the stored messages 53–77 on that subject.

Notice these details:

•

SUE does not miss any REMEMBER.THIS messages. However, the new SUE_PER must gracefully fix any difficulties caused by partial processing of message 53 by the old SUE_PER.

•

JOE and SUE communicate using a public subject name—not an inbox. Inbox names are unique, so they cannot continue beyond transport invalidation.

•

SUE explicitly requires old messages by setting a parameter when creating the persistent correspondent named SUE_PER; this parameter ensures that JOE_PER retransmits certified messages that the previous instance of SUE_PER had not confirmed. If the value of the requireOldMsgs argument were false, JOE_PER would delete stored outbound messages for SUE_PER from its ledger, instead of retransmitting them.