Table of Contents
This chapter introduces HMS and describes its structure. It also explains the basic concept and terminology of a messaging system.
A messaging system is a communication medium that enables loosely coupled relationship between a sender and a receiver. A sender and a receiver do not need to know each other's information. Only the information about a destination (which is a destination) is required for the communication. The send time and the receive times are separated to minimize delays in data transmission. For this, a messaging system guarantees reliability of sending and receiving messages.
Hybrid Messaging System (hereafter HMS) expresses the information exchange status between enterprise systems as the message type data and the virtual channel called a destination. A message created by a user is sent to a destination, which is a virtual channel created by an administrator. Any application can get the information by registering itself to the destination. HMS complies with the concept of JMS (Java Messaging Service), a Java-based messaging system standard of Sun Microsystems, and its operations.
Since HMS runs on the Tmax system, TmaxSoft's TP-Monitor, a user can loosely couple the TP-Monitor and the messaging system functions. System failures can be handled using the 2PC feature with the resource managers (hereafter RM) and the backup node configuration.
HMS operates as a multithreaded process in the Tmax system. The following is the structure of the HMS operation.
HMS threads are divided into main threads and worker threads.
-
Worker thread
A worker thread is divided into a general thread and a storage thread. A storage thread handles tasks related to storage, and a general thread handles the other tasks.
The number of worker threads can be specified in an environment file. The default number of general threads and storage threads is 2 and 4, respectively. The number of storage thread must be set properly according to the performance of the system and storage.
The following is the programming model used in JMS and HMS.
Note
A user needs to have an understanding of basic concept and terminology about a messaging system to use HMS. HMS uses the concept of JMS, so the terminologies used in JMS and HMS are the same.
An application must connect to Tmax to use features of HMS. Server applications can make a connection automatically, but client applications must use tpstart() to connect to Tmax before using HMS APIs. When the connection is terminated with tpend() or due to the termination of the server, the session and client information created by the application will be removed from HMS.
A session is the basic processing unit of using the features of HMS. HMS uses the following 4 sessions: a general session, transacted session, XA session, and async session.
-
General sessions
A session can be made only when the application is connected to Tmax. Multiple sessions can be created in a single application. To create a session, the name of the target HMS is required. Once a session is created, various properties can be assigned to the session.
A session may have the following properties.
Property Description Transacted Option to use the transacted property of the session. Acknowledge Mode Type of the response when a message is received. AUTO_ACK and CLIENT_ACK are currently supported. If set to AUTO_ACK, a response is automatically sent. If set to CLIENT_ACK, the user needs to directly send a response.
-
A transacted session is created with assigned transacted properties. It is usually used for local transactions. The results of sending and receiving a message are not immediately applied to HMS in a transacted session. The application is determined according to the hms_commit() and hms_rollback() APIs.
For example, if a producer that was created by using a transacted session sends multiple messages and executes hms_rollback(), the messages are ignored before arriving at the destination. Like this, the results of receiving a message are applied depending on the hms_commit() and hms_rollback() APIs. Only AUTO_ACK is available in a transacted session.
-
An XA session exists to perform 2PC with HMS and another Resource Manager (RM). The start and the end of a transaction are specified using transaction-related APIs (tx_beggin(), tx_commit(), and tx_rollback()) of Tmax. In the state that a transaction has not started, it acts like a general session.
-
HMS supports not only synchronous sessions where a message is sent after a request is sent but also async sessions where a message can be received without a request. In the cast that a consumer is created with an async session, if listener, the name of a service to be called when a message arrives, is passed, the specified Tmax service is called whenever a messages arrives.
A destination is the place where transmitted messages stay until they are received by the consumer. Each destination has a unique name. There are following two types of a destination.
Producer
A producer is the subject that sends a message to a destination. If the destination is a topic, the producer becomes a publisher and if the destination is a queue, the producer becomes a sender.
The information required to create a producer are the sessions that were created when a connection was made to the Tmax system, the destination name, and the destination type. A producer can set the following properties for sending a message.
| Property | Description |
|---|---|
| Delivery Mode | A message is sent with the persistent or non-persistent property. Since a persistent message is saved in a storage when arriving at a destination, a failure can be recovered. However, a non-persistent message exists only in HMS memory, and will be removed when HMS is terminated or a failure occurs. |
| Priority | Priority when a message is queued in a destination. HMS does not support this currently. |
| Time to Live | Time during which a message is valid in a destination. If the time passed, the message will be no longer delivered to the consumer. HMS supports Time to Live (hereafter TTL) in seconds. |
If a message is successfully sent, each message gets a unique message ID. The message ID exists in a message as a property. A user can check the ID with hms_get_property().
Consumer
A consumer is the subject that receives a message from a destination.
The information required to create a session are the session name, the destination name, the destination type, and the name of the consumer to be created. A message selector can be used to optionally receive messages that have a specific property. To receive asynchronous messages, the name of the services to be called must be specified. A timeout value can be specified to receive the next message that arrives within the specified time interval. If the timeout is not specified, the consumer will be blocked until the next message arrives. The unit is in second.
-
A consumer of a topic is called a subscriber.
A subscriber that has the persistent property is a durable subscriber. A durable subscriber can receive all messages delivered to a destination from when it is created to when it cancels the subscription. When a durable subscriber is disconnected from Tmax, the next messages will be queued in a topic, and when the durable subscriber is reconnected to Tmax, it will continue to receive messages from the queue. HMS identifies a durable subscriber with the name of a subscriber. Therefore, a durable subscriber must have a unique name.
-
A consumer of a queue is a receiver.
A message selector can be set when a receiver is created. It is used to receive only the messages that meets the specified condition. The syntax of a message selector is the same as that of an SQL condition statement.
For example, if there are properties named "Type" and "Month" in a message, the consumer with the following message selector will only receive the message 'news after April'.
"(Type = 'News') AND (Month > 4)"
For more information about a message selector, refer to "Appendix A. Using a Message Selector".
Since a message used in HMS uses a field buffer of Tmax, it can utilize the merits of the buffer. One body and multiple properties may be set in a single message.
The messages used in HMS uses a field buffer ot Tmax so that users can take the advantage of a field buffer. A single message contains one body and multiple properties.
-
It can be set to the following 8 data types that are supported by a field buffer: HMS_CHAR, HMS_SHORT, HMS_INT, HMS_LONG, HMS_FLOAT, HMS_DOUBLE, HMS_STRING, and HMS_CARRAY. A property is set with a name together. The property name must be unique. If a property is set with an existing name, the previous value will be changed.
Creating a message needs a session. And each property needs the space for the property name as well as the data, ensure that enough space has been allocated by considering the size of the message.
The following describes the default scheduled properties defined in HMS. A user cannot define a property with the following property names. Other scheduled properties are not supported currently.
Property Description HMSMessageID
($MessageID)
Unique ID of a message. Since it is issued by HMS, an ID can be checked after a message is successfully sent. It is a hexadecimal 12 characters. HMSTimeStamp
($TimeStamp)
Time period from when a producer sends a message to when it receives a reply. The unit is seconds. HMSDestination
($Destination)
Name of a destination which a message is sent to and received from. HMSDeliveryMode
($DeliveryMode)
Delivery mode of a message; persistent or non-persistent. HMSExpiration
($Expiration)
TTL value specified when a producer sends a message.
QueueBrowser is a kind of a consumer that can check messages in a queue. It receives messages to be checked from a queue, but does not consume the messages. Messages are checked in the order of the newest to the oldest message by default. But, vice versa is also possible. Only one queue is available for a target destination.
Information of persistent messages and durable subscribers is saved in a storage. As soon as HMS starts, it can recover the information that is unhandled and remained in a storage.
Recovery is specified with the following boot options. It can be set for each destination.
| Classification | Description |
|---|---|
| WARM | Recovers information when HMS starts. |
| COLD | Clears information in a storage when HMS starts. |
If a durable subscriber wants to receive messages continuously from the next message after recovery, it must be created with the previous name. Therefore, a durable subscriber must have a unique name. Notice that if a durable subscriber is removed without cancel of subscription, messages that are not received by the subscriber are piled up at a destination.
Multiple HMS can be clustered in a Tmax multi nodes environment. This clustering provides the advantages of the failover and load balancing functions. Destinations that have the same name and the GLOBAP property logically acts like a single destination.
To configure a HMS cluster, HMSPORT must be set in the SVRGROUP clause. To cluster queues, GQINT additionally needs to be set. In the HMS clause, destinations to be clustered must have the same name and GLOBAL=Y must be set.
Clustered HMSs send and receive heartbeat messages to detect a failure of each other. If a HMS does not receive a heartbeat message within the specified HMSHEARTBEAT, it will declare the other HMS failed.
In HMS, the topic with the clustering configuration is called global topic, and the queue with the clustering configuration is called global queue.
-
The messages sent to a global topic are delivered to the global topics of other nodes.
For example, if there are topics named Topic01 in each node, A, B, and C and all the topics have the GLOBAL=Y setting, a message that arrives at Topic01 in A is sent to Topic01 in B and C.
For example, if GLOBAL=Y is set to all nodes (A,B,C) that have the same name of Topic01, the message that have arrived in Topic01 of the node A will be delivered to the Topic01 of B and C.
-
Only one message can exist and be consumed in a global queue unlike a global topic where a copy is delivered to all configured nodes. Therefore, different clustering methods must be used for the global topic and the global queue.
Each HMS sends and receives information about a global queue based on a specific time (HMSGQINT) cycle. The information includes the number of messages that exist in each queue of the current node, the number of connected clients, etc.
Exchanged Information Description Global Queue Information Interval
(GQINT)
Cycle of exchanging status information on HMSs' global queues. Global Queue Threshold
(GQTHR)
Constant value used to calculate the buffer size of a global queue (Buffer size = the number of consumers of the corresponding queue X GQTHR). Global Queue Max Request
(GQMAXREQ)
Maximum number of the messages that can be retrieved at a time from another node when the length of the current queue cannot fill a buffer. Global Queue Full Length
(GQFULL)
Length threshold of a queue, which is set to prevent unbalanced queue lengths. If the length of a queue is longer than this value, a message will be moved to a queue that has shorter length. Messages are buffered in each queue to ensure that the message transmission is smooth. The buffer size is calculated by multiplying the number of consumers that connect to the current queue by the constant (GQTHR) specified by a user.
If the number of messages in a queue is less than the calculated buffer size, messages will be retrieved from another node's queue. The number of messages (GQMAXREQ) that can be obtained at a time can be specified. If this value is large, messages will be filled with small number of requests. However, if it is too large, there may be unnecessary message transmission between nodes.
HMS also has the function to prevent unbalanced queue lengths. It automatically adjusts the lengths of queues if the number of messages exceeds a specific number (GQFULL).