alihan/fn-serverless
1
0
Fork 0
mirror of https://github.com/fnproject/fn.git synced 2022-10-28 21:29:17 +03:00
Code Issues Packages Projects Releases Wiki Activity

Add idle_timeout to routes API (#603)

Browse Source 
* Add inactivity_timeout to routes API

Closes: #544

* Fix failing datastore tests

* Rename inactivity_timeout to idle_timeout

* Update swagger doc

* Update hot fn doc

* Fix json tags

* Add function timeouts docs

* Rewording
This commit is contained in:
Denis Makogon
2017-03-25 19:28:53 +02:00
committed by U Cirello
parent 11d3e29304
commit 7603e6e8fa
12 changed files with 148 additions and 46 deletions
Download Patch File Download Diff File Expand all files Collapse all files

58
docs/function-timeouts.md Normal file
View File

@@ -0,0 +1,58 @@
# Function timeouts
Within Function API, each functions supplied with 2 timeouts parameters, both optional, see [swagger.yaml](swagger.yml) for more details.
So, what are those timeouts and what are they used for?
## Function call timeout
This time of timeouts defines for how long function execution may happen before it'll be terminated along with notifying caller that function terminated with error - timed out.
```json
{
"route":{
...
"timeout": 30,
...
}
}
```
This timeout parameter used with both types of functions: async and sync.
It starts at the beginning of function call.
## Hot function idle timeout
This type of timeout defines for how long should hot function hang around before its termination in case if there are no incoming requests.
```json
{
"route":{
...
"idle_timeout": 30,
...
}
}
```
This timeout parameter is valid for hot functions, see what [hot functions](hot-functions.md) is. By default this parameter equals to 30 seconds.
It starts after last request being processed by hot function.
## Correlation between idle and regular timeout
This two timeouts are independent. The order of timeouts for hot functions:
0. start hot function be sending first timeout-bound request to it
1. make request to function with `timeout`
2. if call finished (no matter successful or not) check for more requests to dispatch
3. if none - start idle timeout
4. if new request appears - stop idle timeout and serve request
5. if none - terminate hot function
## Hot function idle timeout edge cases
Having both timeouts may cause confusion while configuring hot function.
So, there are certain limitations for `idle_timeout` as well as for regular `timeout`:
* Idle timeout might be equal to zero. Such case may lead to satiation when function would be terminated immediately after last request processing, i.e. no idle timeout at all.
* Idle timeout can't be negative.
* Idle timeout can't be changed while hot function is running. Idle timeout is permanent within hot function execution lifecycle. It means that idle timeout should be considered for changing once functions is not running.

7
docs/hot-functions.md
View File

@@ -91,7 +91,8 @@ requests:
"type": "sync",
"config": null,
"format": "http",
"max_concurrency": "1"
"max_concurrency": "1",
"idle_timeout": 30
}
}
```
@@ -100,4 +101,6 @@ requests:
container.
`max_concurrency` (optional) - the number of simultaneous hot functions for
this functions. This is a per-node configuration option. Default: 1
this functions. This is a per-node configuration option. Default: 1
`idle_timeout` (optional) - idle timeout (in seconds) before function termination.

6
docs/swagger.yml
View File

@@ -378,8 +378,12 @@ definitions:
type: string
timeout:
type: integer
default: 60
default: 30
description: Timeout for executions of this route. Value in Seconds
idle_timeout:
type: integer
default: 30
description: Hot functions idle timeout before termination. Value in Seconds
App:
type: object