concept
A trigger monitor is an application that processes the trigger messages that are put on initiation queues when a trigger event occurs.
The trigger monitor is a process used to process trigger messages that are put into the initiation queue when a trigger event occurs;
If triggering is enabled for a queue and a trigger event occurs, the queue manager sends a trigger message to the initiation queue. The trigger monitor reads the trigger message and takes appropriate action, based on the data in the trigger message. Normally, this action would be to start some other application to process the queue that caused the trigger message to be generated. From the point of view of the queue manager, there is nothing special about a trigger monitor; it is just another application that reads messages from a queue (the initiation queue).
If the trigger function of a queue is enabled and a trigger event occurs, QM will send a trigger message to the initiation queue. Based on the data in the trigger message, the trigger monitor reads the trigger message and performs related actions. Under normal circumstances, this action is to start some applications to process the queue that generated the trigger message. From the perspective of QM, the trigger monitor is nothing special, it just reads messages from another queue.
When you have started a trigger monitor, it just continues monitoring the specified initiation queue. You cannot stop a trigger monitor directly. When you stop the trigger monitor's queue manager, the trigger monitor stops too.
When you start a trigger monitor, it just monitors a specific initiation queue. You can stop triggering the monitor directly. But if you stop triggering the QM that monitors it, the trigger monitor stops.
Trigger type
first: trigger when the first message arrives;
every: It will be triggered every time a message arrives;
depth: trigger based on queue depth;
Placement example
In order to have a deeper understanding of the use of triggers, a depth-based trigger is configured in the transmission queue of the sender of a remote queue architecture with a trigger depth of 5 . As shown in the figure: 
Trigger data: DATA is the transmission channel sdr_channel of the sender , and the initiation queue is the system default queue. When a trigger event occurs, QM will send a trigger message to the initiation queue, and the trigger process reads the initiation queue and executes the trigger event (in this case, the sending channel is started);
At first, the sending channel is in the inactive state:
After five messages are put into the remote queue, sdr_channel is automatically triggered and sent to the remote QM queue, and the first four messages are consistently held in the transmission queue. Until the fifth message arrives, sdr_channel is triggered and the message is sent to the remote QM queue.
Extended thinking
- Trigger can be used to trigger a channel, and can also be used to trigger a process . The definition of PROCESS resources in IBM MQ will be shared later;
- What scenarios can triggers be used for? The author believes that it can be used at least for:
a. Flow monitoring and back pressure. For example, triggering based on depth, but the queue depth reaches a certain threshold, triggering a process to back pressure the message producer and requesting it to reduce the sending rate;
b. Sleep when the load is unbalanced. For example, based on the first trigger, you can set the processing process to sleep before the message arrives, and trigger the process when the message arrives.