DCOM Explained
by Rosemary Rock-Evans
Digital Press
ISBN: 1555582168   Pub Date: 09/01/98

Previous Table of Contents Next


Queues

Types of queue

There are three main types of queue supported by MSMQ—transmission queues, target or receipt queues, and dead letter queues.

Transmission queues are queues used by every Routing server to enable messages to be received from other Routing servers (or a client application) and then either transmitted to another Routing server or sent to the final receipt queue. They provide various points of store and forward capability along the route to the final destination queue. Transmission queues are thus held on each node that has a Routing server—including the initial client and the final server hosts.

Messages created/sent by a client application are passed to the local Routing server, which stores them on its local transmission queue. It looks up the Routing table to find out where the final queue is and also which route should be followed to get there. After this route has been determined the message is passed to the next Routing server on the route, which stores the message in its local transmission queue.

This “hopping” from one Routing server to the next (possibly across multiple sites) continues until the final destination is reached and the message is stored on the final destination’s transmission queue. The message is then placed on the final receipt queue from where it can be read by the application(s).


Figure 14.6  Transmission queues

The storage medium used for transmission queues is dependent on the delivery method required for the message. Two delivery methods are supported—recoverable and express. Each message is marked as to the method to be used.

  For each recoverable message, the “write” operation to the transmission queue is automatically flushed to disk. Thus, the transmission queues used for recoverable messages are stored on disk.
  For each express message, the message stays in memory. These memory-based queues, however, can be the subject of journaling. So, even though the message may be memory based, it may still be logged and therefore recoverable in case of machine failure. Other than any logging which takes place, messages may be written to disk when the computer has physically run out of memory and needs somewhere else to put the message. In other words, the disk is used as an overflow.

Transmission queues can be the subject of journaling—the process of logging a message to disk. Two types of journaling are supported. If source journaling is used, the outgoing messages are logged. If this option is used, the logging is configured on a message-by-message basis. If target journaling is used, incoming messages are logged. This form of logging is configured on a per queue basis by the administrator.

Target or receipt queues are the final destination queue for a message before it is read by an application. There are two types of receipt queues—public and private queues.

Public queues-Public queues are queues from which one or more server applications can read. They are thus shared queues. Not only can a public queue be read by more than one process, but a process can read more than one public queue.


Figure 14.7  Public queues

Not only can the queue be shared, but messages can be shared as well. Applications can “peek” at a message or read the message. Applications that peek at the message read without removing the message; applications that read the message cause the message to be removed.

Public queues can have site scope—in which case their contents can be read by anyone on that site, or they can have enterprise scope, in which case their contents can be read by any application in the entire enterprise. Public queues are stored in the MSMQ Information Store along with Directory type information and as such are stored on disk. MSMQ uses MS SQL Server version 6.5 as the underlying DBMS. Because of this, they are automatically replicated along with the rest of the information to the other sites. Queues with site scope are replicated to all BSCs within the site. Queues with enterprise scope are replicated to all controller servers (PECs, PSCs, BSCs) within the enterprise.

The replication that takes place across the enterprise ensures the contents are available across sites and avoids a shared queue from having to be read from multiple sites. Because a replicated copy exists on each site, it is this copy that is used, not one centrally stored one. The replication thus serves to both provide a backup mechanism in case of failure and improve performance.

Applications reading the message from an enterprise queue effectively result in the removal of the same message from other copies of the queue. In effect, therefore, even though the message has been duplicated to the other sites, it only remains on the queue until an application reads that message. Once the message has been read by an application, all duplicate messages are removed.


Figure 14.8  Replication of public queues

If, however, an application peeks at a message, the message simply stays on the queue and, of course, all the duplicate queues. An application is responsible for the removal of messages if they are shared.

Private queues-Private queues cannot be shared—they are used by only one application. Private queues are used for point-to-point communication. One or more clients can place a message on a private queue, but only one application can read from the queue. Private queues are located on the host of the application that will use the queue and are stored in the local Registry of the server host and as such are stored on disk.

Although private queues can only be read by one application, an application can read from more than one private queue and can also read from both a private and public queue. Thus, a server application can be in receipt of various message types, if the designer so wishes.


Figure 14.9  Private queues

Private queues do not support the ability to peek a message—once read, the message is removed from the queue.

Dead letter queues-MSMQ supports “dead lettering”—messages that have expired or are undeliverable are called dead letters and are stored in the dead letter journal. Dead letter journaling is used if the destination queue is not known, the message has exceeded its maximum number of hops, or the message time to live has expired. The dead letter journal can be both viewed and manipulated by the administrator.


Previous Table of Contents Next