Copyright © Cloud Software Group, Inc. All Rights Reserved

Distributed Queue Members

A distributed queue is a group of cooperating transport objects, each in a separate process; each transport object is called a member. From the outside, a distributed queue appears as though a single transport object; inside, the group members act in concert to process inbound task messages. Ordinary transports and CM transports can send task messages to the group; notice that the senders are not group members, and do not do anything special to send messages to a group; rather, they send messages to ordinary subject names (but wildcard subjects are illegal). Inside the group, the member acting as scheduler assigns each task message to exactly one of the other members (which act as workers); only that worker processes the task message.

The members of a distributed queue all share the same reusable correspondent name, indicating that they are members of the distributed queue with that name.

Each member of a distributed queue must listen for the same subjects using CM listener objects. Yet even when n members listen for each inbound message (or task), only one member processes the message.

Certified Delivery Behavior in Queue Members

Group members support a limited subset of certified delivery calls—members can listen to a subject, override automatic confirmation of delivery, and confirm delivery. Member transports do not support calls associated with sending messages.

Distributed queues do not use ledger files. Group members automatically require old messages from certified senders.

Scheduler recovery and task rescheduling are available only when the task message is a certified message (that is, a certified delivery agreement is in effect between the task sender and the distributed queue transport scheduler).

Member Roles—Worker and Scheduler

Each distributed queue member has two distinct roles—as a worker, and as a potential scheduler.

In the worker role, members listen for task messages, and process inbound task messages as assigned by the scheduler.

Rendezvous fault tolerance software maintains exactly one active scheduler in each distributed queue; if the scheduler process terminates, another member assumes the role of scheduler. The member in the scheduler role assigns inbound tasks to workers. (A scheduler can assign tasks to its own worker component, but only does so when all other workers are busy.)

Enforcing Identical Subscriptions

It is important that all members of a distributed queue listen to the same set of subjects. It is good practice that programs enforce this rule among the distributed queue members. The easiest technique for enforcing identical subscriptions is to fix the subscription list within the program code (for example, as a constant).

If one member removes a subscription (that is, it destroys a listener), then it is good practice that all the members also close that subscription. The easiest technique for enforcing this rule is to avoid removing subscriptions at all.

Fault Tolerance versus Distributed Queues

Fault tolerance usually requires that every member of a fault tolerance group receive each message. In contrast, each message to a distributed queue group is received by exactly one worker in the group. These mutually exclusive semantics cannot co-exist in the same distributed application program. That is, a program cannot simultaneously be a member of a fault tolerance group and a member of a distributed queue.

At a lower level, however, distributed queues automatically use fault tolerance software to elect and maintain a scheduler (see Scheduler Parameters).

Copyright © Cloud Software Group, Inc. All Rights Reserved