Introduction

This chapter describes RQ (Reliable Queue) and RQ system components.

1. Overview

When service requests from clients are concentrated to the point where they cannot be processed immediately and instead loaded in the internal queue, all service data will be deleted and lost if the system is terminated abnormally due to a system error. In such cases the services that guarantee reliability cannot run normally. To solve this problem, the Tmax system provides the Reliable queue (RQ) functionality for process services that require reliability and consume a lot of time. This solution is different from other online applications.

RQ stores client requests on a disk to guarantee service, and is used for peer-to-peer communication between clients or servers as a regular queue system.

If RQ is used, reliability can be secured but it can lower performance speed because it writes data to a disk. Therefore, it is suggested to use RQ for jobs that require reliability and are not time sensitive.

2. System Components

Tmax RQ (Reliable Queue) system includes all APIs and commands that write and read service request messages, as well as the service execution results sent by clients to and from a physical device (disk) or virtual device (memory) for managing and operating operations. By using RQ, the results of service requests or service executions will not be lost and unprocessed jobs will be able to be resumed when a contingency arises.

figure 1 1
RQ System Components

The following shows the RQ system components:

  • RQ file system

  • RQS

  • RQ API

  • Management tool

RQ File System

The Tmax RQ system stores actual data managed by RQ but does not use a raw device. When the RQ system starts, Tmax creates a 16~2047 MB file in a user-specified directory as a RQ data file.

The RQ data file is created with the "RQ name.data" name, using the RQ name specified in the Tmax configuration file. The user can set the RQ data file size and an option to reuse a RQ file that has remaining data after the system is terminated. Currently, the RQ data file size is not adjusted automatically in Tmax, so the user must set a proper value.

RQ is divided into the following 3 types:

  • Request queue

    Request data that was processed using tpend() are all stored in the Request queue before executing the service.

  • Reply queue

    All data that is returned after executing a service is stored in the Reply queue regardless of the success or failure of the service. Data without a name specified as a special exception is stored here.

  • Fail queue

    RQ data, which failed to execute a service or was terminated before execution, is stored in the Fail queue.

    Data is stored in the Fail queue in the following cases: When data, which was processed using tpenq(), has not received the normal return result from a server. When a executed service does not exist. When results has not been returned normally from a service. When the Tmax system restarts and the RQ type is set to 'WARM booting' and while data is in the Request queue.

The data stored in RQ can be reused even if the Tmax system was restarted due to a system error or network instability. To recover the data, a configuration must be set in the configuration file. For more information about the configuration file, refer to examples in UCS Using Program.

Data in the Request queue and the Fail queue are all moved to the Fail queue when recovering, however, the data in the Reply queue remains in its queue. Data can be retrieved to execute a service or to be used for other purposes.

figure 1 3
RQ In Case of System Failure
RQS

RQS is a RQ manager that is controlled by a Client Manager (CLH) and manages all processes for storing and reading data to and from an actual RQ file. RQS has its own buffer and keeps data synchronized with the data stored in an actual disk and provides a caching function for service execution. Users can set the method for storing RQS data to a disk.

RQ API

Tmax provides APIs for applications that use the RQ system. For more information about the APIs, refer to API.

Management Tool

Administrators can view or manage RQ system state information using the tmadmin command provided by Tmax. For more information about the RQ system management using tmadmin, refer to System Management.

3. RQ System Flow

The following is the basic RQ system flow. The following figure shows how a client requests a service and receives a result value through RQ.

figure 1 2
RQ System Process

The following describes the RQ system flow.

  1. A client requests a service, or "ATTACK", using tpenq().

  2. The Tmax system handler (hereafter CLH), after receiving the client request, requests the RQS (RQ manager) to process the tpend().

  3. RQS writes the service in the Request queue (disk).

  4. RQS sends the results, which are services that were entered in the request queue, to CLH.

  5. CLH sends a result that the service was processed normally as a response to the service request to the client.

  6. RQS requests to CLH to process the service.

  7. CLH executes the requested service (ATTACK).

  8. The service (ATTACK) performs tpreturn() after executing the routine.

  9. CLH, which received the service (ATTACK) results, sends the results to RQS.

  10. RQS, which received the service process results, writes the results in the Reply queue if successful, or in the Fail queue if failed.

  11. The client requests tpdeq() with the service name (ATTACK).

  12. CLH requests the process results to RQS.

  13. RQS retains the latest information of a disk and sends the response to CLH without additional disk I/O.

  14. CLH sends the response to the client.