System Settings
These are the system settings and limitations to consider when designing and debugging your actions.
429: TOO MANY REQUESTS
if exceeded.X-OW-EXTRA-LOGGING: on
Returns 429: TOO MANY REQUESTS
if exceeded.429: TOO MANY REQUESTS
if exceeded.429: TOO MANY REQUESTS
if exceeded.Sequences and timeout
When invoking a sequence in a blocking manner, there is a 60-second limit for timeout that can't be changed. This means the sum of the execution times of all actions in the sequence must be 60 seconds or less. You can specify a timeout value greater than 60 seconds, but the system will ignore it and impose the 60-second limit.
If one of your actions needs more than 60 seconds (therefore putting the sequence over the limit), the only solution is to invoke it as a non-blocking action using the OpenWhisk npm module. So, using the example above, you could have actionA
calling another action in a non-blocking manner. You can see an example of how to do this here.
Using pre-warmed containers
You can avoid most container cold starts and improve chances of low-latency execution by creating actions that use the default Node version and a memory setting of 256MB
, 512MB
, or 1024MB
.
The system maintains a pool of "pre-warmed" containers with these settings waiting to be used. Incoming calls that can't be sent to an existing running container will be sent to one of the pre-warmed containers, but only if the action's Node version and memory setting match the container's. Use of pre-warmed containers cuts latency because time is spent only to inject action code, not to wait for creation of a container.
Timeout
Changes to the default timeout setting must be done explicitly. For example, this command increases the timeout to 300,000 msec (5 minutes): aio rt:action:create action-name source.js -t 300000
If you plan to increase the timeout to more than one minute, be aware that:
- Blocking calls such as web actions time out in one minute regardless of the timeout setting, and return an error to the caller. But action execution will continue until either it completes or the timeout value is exceeded. Actions that time out produce a Developer error as their result; retrieve it by polling for the activationId, then use it to get the result.
- Asynchronous calls respond immediately with an activationId. Execution continues until the work is done or the timeout value is reached.
Activation TTL
Activation Time To Live (TTL) is seven days. This is a system setting that can't be changed by Developers. If you don't see activations that you know took place, consider whether they exceeded their TTL .
Next step
Return to Guides Index.