Webtask

Documentation

Webtask Containers

Overview and Lifecycle Management

For customized documentation and ready to run samples, please log in.

Webtask containers are named units of isolation for executing code. Each webtask request specifies a webtask container to execute in. If two webtasks execute in different webtask containers, they are guaranteed to be isolated in terms of in-memory state, disk, network, and resource quotas. If two webtasks execute in the same webtask container, no such isolation guarantees exist. Instead, such webtasks may (but are not guaranteed to) execute in the same process.

In-memory caching

A tenant’s webtasks, when executed in the same container, may execute in the same process. This is something you can use for certain in-memory optimization in your webtasks.

For example, as part of your implementation you may need to connect to a custom SQL database to retrieve data. You can use the fact that your code might be executing in the same process to do process level connection pooling using the global object. If the webtasks execute within the same address space then the database connection will be created only once during the lifetime of the process.

function (user, context, cb){
  //if the database connection has not been created
  if (!global.db) {
    global.db = ... //logic to create the db connection
  }

  //logic to access the global.db
}

However, you need to keep in mind that you cannot rely on this, and your code should handle the case where your webtasks did not execute in the same process and hence the database connection is not in fact created, similar to how our sample snippet does.

Built-in Recycle Policies

Webtask runtime has some built-in policies for recycling containers. The condition that can trigger a container recycle can be either a period of inactivity, the reach of maximum container lifetime, or the processing of a specific number of transactions.

Container recycle after a period of inactivity

If a container does not receive new transaction requests for a specific amount of time, it is subject to recycling. All transactions within that container will be given a grace period to finish, and afterwards the container will be terminated by the webtask runtime.

Container recycle after a set period of time

Each container has a maximum life period. When this amount of time is exceeded then the container is recycled, regardless of how active it is. When this happens the the webtask runtime gracefully terminates the running webtasks, provisions a new container, and redirects all new transactions to the new container.

Container recycle after a number of transactions

Each container allows for a maximum number of transactions to be processed, after which the container is subject to recycling.

Default values

The default values for the public cluster are the following:

  • Period of inactivity = 30 seconds
  • Grace period = 5 seconds
  • Maximum lifetime of a container = 20 minutes
  • Maximum number of transactions prior to recycling = 100K

These values are configurable for users that have a dedicated cluster.

Exceptions

Another factor that may force your container to recycle is an unhandled exception in the webtask script code. An unrecoverable error may crash the node process and this will affect all the webtasks running on this process.

When this happens the container is in quarantine for a short period of time. This measure is meant to prevent DDoS attacks. In this case the user will get an HTTP response with 429 status code, and an error message in the response body indicating the container is under quarantine.