Basic settings |
Trigger Type |
Select Message Queue for Apache RocketMQ from the drop-down list.
|
Message Queue for Apache RocketMQ |
Name |
Enter a trigger name. |
rocketmq-trigger |
Version or Alias |
The default value is LATEST. If you want to create a trigger for another version or alias, switch to the specified
version or alias in the upper-right corner of the function details page. For more
information about versions and aliases of a service, see Manage versions and Manage aliases.
|
LATEST |
Apache RocketMQ Instance |
Select a Message Queue for Apache RocketMQ instance from the drop-down list.
|
MQ_INST_164901546557****_BX7**** |
Topic |
Select a topic of the Message Queue for Apache RocketMQ instance from the drop-down list.
|
topic1 |
Tag |
Specify a tag for message filtering.
The execution of a function is triggered only when a message that contains the specified
filtering tag is received.
|
tag |
Group ID |
Select the group ID of the created Message Queue for Apache RocketMQ instance.
|
GID_group1 |
Consumer Offset |
Select a consumer offset of the message. A consumer offset specifies the point at
which Message Queue for Apache RocketMQ starts to pull messages from the event bus. Valid values:
- Latest Offset: consumes messages from the latest offset.
- Earliest Offset: consumes messages from the earliest offset.
- Timestamp: consumes messages from the specified timestamp.
|
Latest Offset |
Advanced settings |
Invocation Method |
Select a method to invoke the function.
Valid values:
- Synchronous Invocation: After an event triggers a function, Function Compute returns the execution result when the execution is complete. This is the default
value. For more information, see Synchronous invocations.
- Asynchronous Invocation: After an event triggers a function, Function Compute immediately returns a response and ensures that the function is executed at least
once. However, the detailed execution result is not returned. This invocation method
is suitable for functions that have higher scheduling latency. For more information
about asynchronous invocation, see Overview.
|
Synchronous Invocation |
Message Push Model |
The underlying application model when message data is pushed to Function Compute.
Valid values:
- Event Model: Each message is passed into a function as an event parameter. The event follows
the specifications for CloudEvents. For information about the relationship between
message content and CloudEvents, see Step 2: Configure the input parameters of the function.
- Event Stream Model: One or more messages are passed into a function in batches based on your batch configurations.
This model is suitable for scenarios in which end-to-end streaming data is processed.
|
Event Model |
Batch Push |
This parameter is available only if you select Event Stream Model as the message push model.
Batch push helps you aggregate multiple events. Batch push is triggered when the conditions
of either Batch Push Messages or Batch Push Interval are met.
For example, if you set Batch Push Messages to 100 and Batch Push Interval to 15 seconds,
the batch push is triggered immediately when the number of messages reaches 100 in
less than 15 seconds.
|
Enable |
Batch Push Messages |
The maximum number of messages that are sent by each function invocation in a batch.
Requests are sent when the number of backlog messages reaches the specified value.
Valid values: 1 to 500.
|
1 |
Batch Push Interval |
The time interval at which the function is invoked. The system sends the aggregated
messages to Function Compute at the specified time interval. Valid values: 0 to 15.
Unit: seconds. A value of 0 indicates that messages are sent immediately after aggregation.
|
1 |
Retry Policy |
This parameter is available only if you select Event Stream Model as the message push model.
The retry policy to be used when a message fails to be pushed.
Valid values:
- Backoff Retry: A message push request can be retried for up to three times at random intervals
in the range of 10 to 20 seconds.
- Exponential Decay Retry: A message push request can be retried for up to 176 times, and the retry lasts for
a maximum of one day. The interval between each retry is increased by a factor of
2 up to a maximum of 512 seconds: 1, 2, 4, 8, ... 512 seconds.
|
Backoff Retry |
Fault Tolerance Policy |
This parameter is available only if you select Event Stream Model as the message push model.
The method to handle errors.
Valid values:
- Fault Tolerance Allowed: Fault tolerance is allowed. Event processing is not blocked when an error occurs.
The messages that fail after they are retried based on the retry policy are delivered
to dead-letter queues or discarded based on your configurations.
- Fault Tolerance Prohibited: Fault tolerance is prohibited. If an error occurs and the message fails after it
is retried based on the retry policy, event processing is blocked.
|
Fault Tolerance Allowed |
Dead-letter Queue |
This parameter is available only if you select Event Stream Model as the message push model.
The message queue to which events that are not processed or have exceeded the number
of retries are sent. If you disable this feature, messages that have exceeded the
number of retries specified by the retry policy are discarded.
|
Enable Dead-letter Queue |
Queue Type |
The type of the dead-letter queue.
Valid values:
- MNS
- Message Queue for Apache RocketMQ
|
MNS |
Queue Name |
The name of the dead-letter queue. |
test-queue |