[
https://issues.jboss.org/browse/MODCLUSTER-645?page=com.atlassian.jira.pl...
]
Radoslav Husar commented on MODCLUSTER-645:
-------------------------------------------
This is really suboptimal, because one needs to adjust the value in mod_cluster depending
on which LB it is consulting.
The mod_cluster native implementation delegates the value to mod_proxy,
https://httpd.apache.org/docs/2.4/mod/mod_proxy.html#proxypass, which is defined as:
* Maximum number of failover attempts before giving up.
* default: One less than the number of workers, or 1 with a single worker.
while Undertow always defined it as total number of *attempts* as opposed to *failover
attempts*.
I am not ever sure which one is 'better'. If it is failover attempts, they should
have called it max-failover-attempts.
Different handling of max-attempts parameter on Undertow and httpd
implementation
---------------------------------------------------------------------------------
Key: MODCLUSTER-645
URL:
https://issues.jboss.org/browse/MODCLUSTER-645
Project: mod_cluster
Issue Type: Bug
Affects Versions: 1.3.5.Final
Reporter: Jan Kašík
Assignee: Radoslav Husar
The behavior of balancer is different on httpd in comparsion with Undertow implementation
when max-attempts parameter is set.
* *Undertow*: max-attempts is total count of requests made by balancer in failover
scenario. When max-attemps is set to 1 and target worker fails after first attempt made by
balancer, no further attempts are made.
* *httpd*: max-attempts is count of retries made by balancer after first attempt fails.
When max-attempts is set to 1 and target worker fails after first attempt made by
balancer, second worker is chosen and request is sent towards it.
This doesn't seem right and I suggest to unify behavior across implementations.
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)