Async

• The HTTP request is serialized to NATS Streaming through the gateway as a "producer".

The asynchronous workflow can have a longer, separate timeout compared with synchronous timeout on the gateway.

Example:

You're working with a partner's webhook. They send you data, but if you don't send a HTTP 200 OK within 1 second, they assume failure and retry the message. This works well if your function can complete in less than a second on every invocation, but if there's any risk that it can't, you need another solution. So you will give your partner a URL to the asynchronous function URL instead and it will reply within several milliseconds whilst still processing the data.

If you would like to receive a value from an asynchronous call you should pass a HTTP header with the URL to be used for the call-back.

It will pass back the X-Call-Id you had when you sent the initial request.

You can use to check the Call Id during invocation:

Parallelism

By default there is one queue-worker replica deployed which is set up to run a single task of up to 30 seconds in duration with one task in parallel. You can increase the parallelism by scaling the queue-worker up - i.e. 5 replicas for 5 parallel tasks.

You can tune the values for the number of tasks each queue worker may run in parallel as well as the maximum duration of any asynchronous task that worker processes. Edit the Kubernetes helm chart, YAML or Swarm docker-compose.yml files.

The has more instructions on running tasks asynchronously.

• Verbose Output

Callback request headers

The following additional request headers will be set when invoking the call back URL: