3. Architectures
The same Ultra Messaging® API may be used for stream-based messaging or persistent messaging and queuing . Similarly, the umestored daemon can be configured as a persistent store or queue, providing consistent and efficient operation across persistent and queuing messaging systems.
3.1. Persistence Architecture
As shown in the diagram, UMP provides messaging functionality as well as persistent operation. See UMP Persistence Architecture for an overview of UMP architecture.
The highlights of this architecture are:
-
Sources communicate with stores
-
Receivers communicate with stores
-
Sources communicate with receivers
Note: The persistent store does not lie in the middle of the data path between source and receivers. Along with other enhancements, this feature, called Parallel Persistence®, gives UMP a significant performance edge over any other persistent messaging product.
Note: The persistent store is not supported on the HP NonStop® platform.
3.2. Persistent Store Architecture
The umestored daemon runs the UMP persistent store feature. You can configure multiple stores per daemon using the <store> element in the umestored XML configuration file. See Configuration Reference for Umestored. Individual stores can use separate disk cache and disk state directories and be configured to persist messages for multiple sources (topics), which are referred to as, source repositories. UMP provides each umestored daemon with a Web Monitor for statistics monitoring. See Ultra Messaging Web Monitor.
This section discusses the following topics.
3.2.1. Source Repositories
Within a store, you configure repositories for individual topics and each can have their own s et of <topic> level options that affect the repository's type, size, liveness behavior and much more. If you have multiple sources sending on the same topic, UMP creates a separate repository for each source. UMP uses the repository options configured for the topic to apply to each source's repository. If you specify 48MB for the size of the repository and have 10 sources sending on the topic, the persistent store requires 480MB of storage for that topic.
A repository can be configured as one of the following types.
-
no cache - the repository does not retain any data, only state information
-
memory - the repository maintain both state and data only in memory
-
disk - the repository maintains state and data on disk, but also uses a memory cache.
-
reduced-fd - the repository maintains state and data on disk, also uses a memory cache but uses significantly fewer File Descriptors. Normally a store uses two File Descriptors per topic in addition to normal UM file descriptors for transports and other objects. The reduced-fd repository type uses 5 File Descriptors for the entire store, regardless of the number of topics, in addition to normal UM file descriptors for transports and other objects. Use of this repository type may impact performance.
You can configure any combination of repository types within a single store configuration.
Note: If you run a store with all disk or reduced-fdtype repositories, then restart the store with memory type repositories and do not clear out the disk-cache-directory and disk-state-directory, the memory repositories revert automatically to disk repositories.
Note: With UMP Version 5.3, the UMP store daemon has Standard C++ Library dependencies for Unix packages. The libstdc++ must also be included in LD_LIBRARY_PATH. See Section 3. Code for more infromation.
3.2.2. Persistent Store Fault Tolerance
Sources and receivers register with a store and use individual repositories within the store. Sources can use redundant repositories configured in multiple stores in either a Round Robin or Quorum/Consensus arrangement for fault tolerance. Stores and repositories have no indication of these arrangements.
The following diagram depicts an example Quorum/Consensus configuration of stores and repositories. These stores could also be run by a single umestored daemon or one daemon for each store.
See Store Configuration Considerations and also Stores Element for more about store configuration.
3.3. Queuing Architecture
The architecture of Queues follows a lot of the same tenets as the UMP persistence architecture. Source and receiver applications can create sources, listen on topics and do normal operations typical of UM applications. Receivers require no special configuration to receive messages from a queue.
The central components to any queuing deployment are:
-
the source applications
-
the receiving applications
-
the umestored daemon, which provides queue instances
The umestored daemon provides separate Queue instances. Just as umestored may contain individual UMP stores, it may also contain individual queue instances as well.
