Advanced features of triggers - Function Compute - Alibaba Cloud Documentation Center

This topic describes advanced features of triggers.

Usage notes

The advanced features described in this topic are only applicable to custom event source triggers, including Simple Message Queue (formerly MNS) queue triggers, ApsaraMQ for RocketMQ triggers, ApsaraMQ for RabbitMQ triggers, ApsaraMQ for Kafka triggers, and Data Transmission Service (DTS) triggers.

Invocation methods

Triggers for Function Compute support synchronous invocations and asynchronous invocations. The following table describes the limits of the two methods.

Invocation method	`body` size limit	Maximum timeout period
Synchronous invocation	32 MB	5 minutes
Asynchronous invocation	128 KB	5 minutes

Push configurations

Note

You must use the limit on the body size to determine whether to reduce the number of aggregated messages in batch pushing. For more information about the limits on the size of body, see Invocation methods.

Batch pushing

After you enable batch pushing, you must configure the Batch Push Messages and Batch Push Interval parameters.

Batch Push Messages: the maximum number of messages that are sent for each invocation. Requests are sent when the number of messages in the backlog reaches the specified value. Valid values: [1, 10000].
Batch Push Interval: the interval at which the function is invoked. The system aggregates messages and sends the messages to Function Compute at the specified time interval. Valid values: 0 to 15. Unit: seconds. A value of 0 indicates that the messages are sent in real time.

Batch pushing helps you aggregate multiple events. When one of the conditions of the Batch Push Messages and Batch Push Interval parameters is met, the function is triggered and request messages are pushed to Function Compute at a time.

Examples of batch pushing

Example 1
Batch Push Messages is set to 100 and Batch Push Interval is set to 15s. The size of each message is 1 KB. The number of messages reaches 100 in 10s. In this case, the messages are immediately sent without waiting for 15 seconds.
Example 2
Batch Push Messages is set to 100 and Batch Push Interval is set to 15s. The size of each message is 1 KB. The number of messages is 50 when the interval reaches 15s. In this case, the messages are immediately sent without waiting for the number of messages to reach 100.
Example 3
Batch Push Messages is set to 100 and Batch Push Interval is set to 15s. The size of each message is 2 KB. Invocation Method is set to Asynchronous Invocation. The number of messages reaches 100 in 10s and the size of the messages reaches 200 KB (100 x 2 KB) which exceeds the upper limit of the body size for asynchronous invocations. In this case, messages are immediately sent in two batches. 64 messages are pushed to Function Compute in the first batch and 36 messages are pushed to Function Compute in the second batch.

Push format

A push format specifies the format of data elements in the event parameter.

CloudEvents: A specification for describing event data in a common format. CloudEvents simplifies event declaration and transmission between different services and platforms.
RawData: Only the content of data fields in CloudEvents is delivered. Other metadata in the CloudEvents format is not delivered.

The following example shows the event of CloudEvents and RawData formats in Simple Message Queue (formerly MNS) queue triggers in the event mode.

CloudEvents

[
    {
    "id":"c2g71017-6f65-fhcf-a814-a396fc8d****",
    "source":"MNS-Function-mnstrigger",
    "specversion":"1.0",
    "type":"mns:Queue:SendMessage",
    "datacontenttype":"application/json; charset=utf-8",
    "subject":"acs:mns:cn-hangzhou:164901546557****:queues/zeus",
    "time":"2021-04-08T06:28:17.093Z",
    "aliyunaccountid":"164901546557****",
    "aliyunpublishtime":"2021-10-15T07:06:34.028Z",
    "aliyunoriginalaccountid":"164901546557****",
    "aliyuneventbusname":"MNS-Function-mnstrigger",
    "aliyunregionid":"cn-chengdu",
    "aliyunpublishaddr":"42.120.XX.XX",
    "data":{
        "requestId":"606EA3074344430D4C81****",
        "messageId":"C6DB60D1574661357FA227277445****",
        "messageBody":"TEST"
    }
    },
    {
    "id":"d2g71017-6f65-fhcf-a814-a396fc8d****",
    "source":"MNS-Function-mnstrigger",
    "specversion":"1.0",
    "type":"mns:Queue:SendMessage",
    "datacontenttype":"application/json; charset=utf-8",
    "subject":"acs:mns:cn-hangzhou:164901546557****:queues/zeus",
    "time":"2021-04-08T06:28:17.093Z",
    "aliyunaccountid":"164901546557****",
    "aliyunpublishtime":"2021-10-15T07:06:34.028Z",
    "aliyunoriginalaccountid":"164901546557****",
    "aliyuneventbusname":"MNS-Function-mnstrigger",
    "aliyunregionid":"cn-chengdu",
    "aliyunpublishaddr":"42.120.XX.XX",
    "data":{
        "requestId":"606EA3074344430D4C81****",
        "messageId":"C6DB60D1574661357FA227277445****",
        "messageBody":"TEST"
    }
    }
]

RawData

[
    {
        "requestId":"606EA3074344430D4C81****",
        "messageId":"C6DB60D1574661357FA227277445****",
        "messageBody":"TEST"
    },
    {
        "requestId":"606EA3074344430D4C81****",
        "messageId":"C6DB60D1574661357FA227277445****",
        "messageBody":"TEST"
    }
]

Retry policies

Failed function requests can be retried based on the configured retry policies. The following items describe the available retry policies:

Backoff Retry: The system retries the request up to three times. The interval between two consecutive retries ranges from 10 to 20 seconds.
Exponential Decay Retry: The default retry policy. The system retries the request up to 176 times. The time interval for each retry exponentially increases to 512s. The total retry time is 24 hours. The retry interval is 1s, 2s, 4s, 8s, 16s, 32s, 64s, 128s, 256s, and 512s. The interval of 512s is used for 167 times.

Scenarios in which retries are triggered

429 error: Requests are throttled by Function Compute. The throttling is temporary and the requests are retried.
5xx error: A function failed to be executed because of a system error in Function Compute.

FAQ

Q: Does a function execution error caused by function implementation issues trigger a retry policy?

A: For synchronous invocations, retry policies are triggered by function execution errors. For asynchronous invocations, retry policies are not triggered by function execution errors. However, retries of asynchronous invocations are triggered. For more information, see Retry policy.

The following two types of function retries are included:

Retries may succeed.
You can retry the requests within the function without the need to execute the retry policy.
Retries are bound to fail.
Retries are meaningless and increase the retry cost.

Fault tolerance policies

A fault tolerance policy specifies whether to ignore errors during executions.

Fault Tolerance Allowed
The system skips the requests that failed to be executed and retried and continues to process the next request.
Fault Tolerance Prohibited
The consumption tasks are blocked when a request fails to be executed and retried.

Dead-letter queues

You can configure dead-letter queues only when Fault Tolerance Allowed is enabled.

If you enable the dead-letter queue feature, messages that are not processed or whose maximum number of retries are reached are delivered to the specified destination services. The destination services for dead-letter queues supported by Function Compute include Simple Message Queue (formerly MNS), ApsaraMQ for RocketMQ, ApsaraMQ for Kafka, and EventBridge. You can select different queue types based on your business requirements.
If you do not enable the dead-letter queue feature, messages whose maximum number of retries are reached are discarded.

Note

For asynchronous invocations, messages are not delivered to the dead-letter queue of the trigger when a function error occurs. In this case, messages are delivered to the destination services that are configured in Function Compute for asynchronous invocations. For more information, see Result callback.