Configuration Manual
-version 3.2-dev1-65
+version 3.2-dev1-74
2024/12/11
@@ -7183,13 +7185,15 @@
2.9.<
- tune.http.maxhdr
- tune.idle-pool.shared
- tune.idletimer
+ - tune.lua.burst-timeout
- tune.lua.forced-yield
+ - tune.lua.log.loggers
+ - tune.lua.log.stderr
- tune.lua.maxmem
- tune.lua.service-timeout
- tune.lua.session-timeout
+ - tune.lua.smp-preserve-bool
- tune.lua.task-timeout
- - tune.lua.log.loggers
- - tune.lua.log.stderr
- tune.max-checks-per-thread
- tune.maxaccept
- tune.maxpollevents
@@ -9048,28 +9052,6 @@ 3.2.<
using "off" for troubleshooting, or for situations where connections are
short-lived and it is estimated that the operating system already provides a
good enough distribution. The default is "on".
-This directive forces the Lua engine to execute a yield each <number> of
-instructions executed. This permits interrupting a long script and allows the
-HAProxy scheduler to process other tasks like accepting connections or
-forwarding traffic. The default value is 10000 instructions for scripts loaded
-using "lua-load-per-thread" and MAX(500, 10000 / nbthread) instructions for
-scripts loaded using "lua-load" (it was found to be an optimal value for
-performance while taking care of not creating thread contention with multiple
-threads competing for the global lua lock).
-
-If HAProxy often executes some Lua code but more responsiveness is required,
-this value can be lowered. If the Lua code is quite long and its result is
-absolutely required to process the data, the <number> can be increased, but
-the value should be set wisely as in multithreading context it could increase
-contention.
-
Sets the maximum amount of RAM in megabytes per process usable by Lua. By
-default it is zero which means unlimited. It is important to set a limit to
-ensure that a bug in a script will not result in the system running out of
-memory.
-
This is the execution timeout for the Lua sessions. This is useful for
-preventing infinite loops or spending too much time in Lua. This timeout
-counts only the pure Lua runtime. If the Lua does a sleep, the sleep is
-not taken in account. The default timeout is 4s.
The "burst" execution timeout applies to any Lua handler. If the handler
fails to finish or yield before timeout is reached, it will be aborted to
prevent thread contention, to prevent traffic from not being served for too
@@ -9118,14 +9100,20 @@ 3.2.<
- increasing tune.lua.burst-timeout
Setting value to 0 completely disables this protection.
-
This is the execution timeout for the Lua services. This is useful for
-preventing infinite loops or spending too much time in Lua. This timeout
-counts only the pure Lua runtime. If the Lua does a sleep, the sleep is
-not taken in account. The default timeout is 4s.
-
Purpose is the same as "tune.lua.session-timeout", but this timeout is
-dedicated to the tasks. By default, this timeout isn't set because a task may
-remain alive during of the lifetime of HAProxy. For example, a task used to
-check servers.
+
This directive forces the Lua engine to execute a yield each <number> of
+instructions executed. This permits interrupting a long script and allows the
+HAProxy scheduler to process other tasks like accepting connections or
+forwarding traffic. The default value is 10000 instructions for scripts loaded
+using "lua-load-per-thread" and MAX(500, 10000 / nbthread) instructions for
+scripts loaded using "lua-load" (it was found to be an optimal value for
+performance while taking care of not creating thread contention with multiple
+threads competing for the global lua lock).
+
+If HAProxy often executes some Lua code but more responsiveness is required,
+this value can be lowered. If the Lua code is quite long and its result is
+absolutely required to process the data, the <number> can be increased, but
+the value should be set wisely as in multithreading context it could increase
+contention.
Enables ('on') or disables ('off') logging the output of LUA scripts via the
loggers applicable to the current proxy, if any.
@@ -9142,6 +9130,39 @@ 3.2.<
configured via tune.lua.log.loggers.
Defaults to 'auto'.
+
Sets the maximum amount of RAM in megabytes per process usable by Lua. By
+default it is zero which means unlimited. It is important to set a limit to
+ensure that a bug in a script will not result in the system running out of
+memory.
+
This is the execution timeout for the Lua services. This is useful for
+preventing infinite loops or spending too much time in Lua. This timeout
+counts only the pure Lua runtime. If the Lua does a sleep, the sleep is
+not taken in account. The default timeout is 4s.
+
This is the execution timeout for the Lua sessions. This is useful for
+preventing infinite loops or spending too much time in Lua. This timeout
+counts only the pure Lua runtime. If the Lua does a sleep, the sleep is
+not taken in account. The default timeout is 4s.
+
Purpose is the same as "tune.lua.session-timeout", but this timeout is
+dedicated to the tasks. By default, this timeout isn't set because a task may
+remain alive during of the lifetime of HAProxy. For example, a task used to
+check servers.
+
Explicitly tell haproxy how haproxy sample objects should be handled when
+pushed to Lua. Indeed, when using native converters or sample fetches from
+Lua script, haproxy converts the smp type to equivalent Lua type. Because
+of historical implementation, there is an ambiguity around boolean
+handling: when doing Lua -> haproxy smp conversion, booleans are properly
+preserved, but when doing haproxy smp -> Lua conversion, booleans were
+converted to integers. This means that a sample fetch or converter returning
+a boolean would return an integer 0 or 1 when leveraged from Lua.
+Unfortunately, in Lua, booleans and integers are not interchangeable. Thus,
+to avoid ambiguities, "tune.lua.smp-preserve-bool" must explicitly be set to
+either "on" (which means dropping the historical behavior for better
+consistency) or "off" (enforce historical behavior to prevent existing script
+logic from misbehaving). If the option is not set explicitly and a Lua script
+is loaded from the configuration, haproxy will emit a warning, and the option
+will implicitly default to "off" to match with the historical behavior. When
+possible, it is recommended to set this option to "on" after ensuring that
+in-use Lua scripts are properly handling bool haproxy samples as booleans.
Sets the number of active checks per thread above which a thread will
actively try to search a less loaded thread to run the health check, or
queue it until the number of active checks running on it diminishes. The
@@ -22845,7 +22866,17 @@ 5.2.<
server, provided that at the end of the chain, a server has health checks
enabled. If <backend> is omitted the current one is used. If disable-on-404 is
used, it has to be enabled on both proxies.
-
May be used in the following contexts: tcp, http, log, peers, ring
+
+Example :
+
+backend A
+server a1 1.1.1.1:80 track B/b1
+server a2 1.1.1.2:80 track B/b1
+
+backend B
+server b1 2.2.2.2:80 check
+
+May be used in the following contexts: tcp, http, log, peers, ring
This option may be used as "server" setting to reset any "no-tls-tickets"
setting which would have been inherited from "default-server" directive as
@@ -31727,7 +31758,7 @@ 11
- HAProxy 3.2-dev1-65 – Configuration Manual
+ HAProxy 3.2-dev1-74 – Configuration Manual
, 2024/12/11
This directive forces the Lua engine to execute a yield each <number> of -instructions executed. This permits interrupting a long script and allows the -HAProxy scheduler to process other tasks like accepting connections or -forwarding traffic. The default value is 10000 instructions for scripts loaded -using "lua-load-per-thread" and MAX(500, 10000 / nbthread) instructions for -scripts loaded using "lua-load" (it was found to be an optimal value for -performance while taking care of not creating thread contention with multiple -threads competing for the global lua lock). - -If HAProxy often executes some Lua code but more responsiveness is required, -this value can be lowered. If the Lua code is quite long and its result is -absolutely required to process the data, the <number> can be increased, but -the value should be set wisely as in multithreading context it could increase -contention. -
Sets the maximum amount of RAM in megabytes per process usable by Lua. By -default it is zero which means unlimited. It is important to set a limit to -ensure that a bug in a script will not result in the system running out of -memory. -
This is the execution timeout for the Lua sessions. This is useful for -preventing infinite loops or spending too much time in Lua. This timeout -counts only the pure Lua runtime. If the Lua does a sleep, the sleep is -not taken in account. The default timeout is 4s.
The "burst" execution timeout applies to any Lua handler. If the handler fails to finish or yield before timeout is reached, it will be aborted to prevent thread contention, to prevent traffic from not being served for too @@ -9118,14 +9100,20 @@3.2.< - increasing tune.lua.burst-timeout Setting value to 0 completely disables this protection. -
This is the execution timeout for the Lua services. This is useful for -preventing infinite loops or spending too much time in Lua. This timeout -counts only the pure Lua runtime. If the Lua does a sleep, the sleep is -not taken in account. The default timeout is 4s. -
Purpose is the same as "tune.lua.session-timeout", but this timeout is -dedicated to the tasks. By default, this timeout isn't set because a task may -remain alive during of the lifetime of HAProxy. For example, a task used to -check servers. +
This directive forces the Lua engine to execute a yield each <number> of +instructions executed. This permits interrupting a long script and allows the +HAProxy scheduler to process other tasks like accepting connections or +forwarding traffic. The default value is 10000 instructions for scripts loaded +using "lua-load-per-thread" and MAX(500, 10000 / nbthread) instructions for +scripts loaded using "lua-load" (it was found to be an optimal value for +performance while taking care of not creating thread contention with multiple +threads competing for the global lua lock). + +If HAProxy often executes some Lua code but more responsiveness is required, +this value can be lowered. If the Lua code is quite long and its result is +absolutely required to process the data, the <number> can be increased, but +the value should be set wisely as in multithreading context it could increase +contention.
Enables ('on') or disables ('off') logging the output of LUA scripts via the
loggers applicable to the current proxy, if any.
@@ -9142,6 +9130,39 @@ 3.2.<
configured via tune.lua.log.loggers.
Defaults to 'auto'.
+
Sets the maximum amount of RAM in megabytes per process usable by Lua. By +default it is zero which means unlimited. It is important to set a limit to +ensure that a bug in a script will not result in the system running out of +memory. +
This is the execution timeout for the Lua services. This is useful for +preventing infinite loops or spending too much time in Lua. This timeout +counts only the pure Lua runtime. If the Lua does a sleep, the sleep is +not taken in account. The default timeout is 4s. +
This is the execution timeout for the Lua sessions. This is useful for +preventing infinite loops or spending too much time in Lua. This timeout +counts only the pure Lua runtime. If the Lua does a sleep, the sleep is +not taken in account. The default timeout is 4s. +
Purpose is the same as "tune.lua.session-timeout", but this timeout is +dedicated to the tasks. By default, this timeout isn't set because a task may +remain alive during of the lifetime of HAProxy. For example, a task used to +check servers. +
Explicitly tell haproxy how haproxy sample objects should be handled when +pushed to Lua. Indeed, when using native converters or sample fetches from +Lua script, haproxy converts the smp type to equivalent Lua type. Because +of historical implementation, there is an ambiguity around boolean +handling: when doing Lua -> haproxy smp conversion, booleans are properly +preserved, but when doing haproxy smp -> Lua conversion, booleans were +converted to integers. This means that a sample fetch or converter returning +a boolean would return an integer 0 or 1 when leveraged from Lua. +Unfortunately, in Lua, booleans and integers are not interchangeable. Thus, +to avoid ambiguities, "tune.lua.smp-preserve-bool" must explicitly be set to +either "on" (which means dropping the historical behavior for better +consistency) or "off" (enforce historical behavior to prevent existing script +logic from misbehaving). If the option is not set explicitly and a Lua script +is loaded from the configuration, haproxy will emit a warning, and the option +will implicitly default to "off" to match with the historical behavior. When +possible, it is recommended to set this option to "on" after ensuring that +in-use Lua scripts are properly handling bool haproxy samples as booleans.
Sets the number of active checks per thread above which a thread will actively try to search a less loaded thread to run the health check, or queue it until the number of active checks running on it diminishes. The @@ -22845,7 +22866,17 @@5.2.< server, provided that at the end of the chain, a server has health checks enabled. If <backend> is omitted the current one is used. If disable-on-404 is used, it has to be enabled on both proxies. -
May be used in the following contexts: tcp, http, log, peers, ring +
+Example :
+
+backend A
+server a1 1.1.1.1:80 track B/b1
+server a2 1.1.1.2:80 track B/b1
+
+backend B
+server b1 2.2.2.2:80 check
+
+May be used in the following contexts: tcp, http, log, peers, ring This option may be used as "server" setting to reset any "no-tls-tickets" setting which would have been inherited from "default-server" directive as @@ -31727,7 +31758,7 @@11
- HAProxy 3.2-dev1-65 – Configuration Manual
+ HAProxy 3.2-dev1-74 – Configuration Manual
, 2024/12/11