Details
-
Bug
-
Resolution: Done
-
Minor
-
19.0.0.Beta1
-
None
-
Workaround Exists
-
Description
In the reverse-proxy configuration the options max-request-time and connection-idle-timeout are specified and managed as seconds in CLI, when they are really milliseconds in undertow.
/subsystem=undertow/configuration=handler/reverse-proxy=LBProxy:read-resource-description
...
"connection-idle-timeout" => {
"type" => INT,
"description" => "The amount of time a connection can be idle before it will be closed. Connections will not time out
once the pool size is down to the configured minimum (as configured by cached-connections-per-thread)",
"expressions-allowed" => true,
"required" => false,
"nillable" => true,
"default" => 60L,
"unit" => "SECONDS",
"access-type" => "read-write",
"storage" => "configuration",
"restart-required" => "all-services"
},
...
"max-request-time" => {
"type" => INT,
"description" => "The maximum time that a proxy request can be active for, before being killed",
"expressions-allowed" => true,
"required" => false,
"nillable" => true,
"default" => -1,
"unit" => "SECONDS",
"access-type" => "read-write",
"storage" => "configuration",
"restart-required" => "all-services"
},
...
The class ReverseProxyHandler just passes the value (no modification) to undertow and it's clearly millis in undertow, for example the max-request-time.
I has suffered this confusion myself doing some tests, I set 60 as the max request time, and it was too short in my env (because they are millis instead of seconds).
We need to change description to millis to respect current configurations.
