[JBoss JIRA] (MODCLUSTER-652) Documentation 2.0
by Radoslav Husar (JIRA)
[ https://issues.jboss.org/browse/MODCLUSTER-652?page=com.atlassian.jira.pl... ]
Radoslav Husar updated MODCLUSTER-652:
--------------------------------------
Description:
Update of the original effort for choosing documentation platform [1].
Problem:
* Documentation is out of date because its painful to edit.
* Too many obstacles to contribute to documentation (difficult format, unclear where, need accounts, doesn't render immediately)
Additional/updated requirements:
* standardized on AsciiDocs
* readers/users are provided with a link to update the documentation on github, submit PR, merge
* automatically built and automatically deployed -- live within 1-2 minutes
[1] https://developer.jboss.org/wiki/ChoosingDocumentationPlatformForModcluster
was:
Update of the original effort for choosing documentation platform [1].
Additional/updated requirements:
* standardized on AsciiDocs
* users are provided with a link to update the documentation on github, submit PR, merge
* automatically built and automatically deployed
[1] https://developer.jboss.org/wiki/ChoosingDocumentationPlatformForModcluster
> Documentation 2.0
> -----------------
>
> Key: MODCLUSTER-652
> URL: https://issues.jboss.org/browse/MODCLUSTER-652
> Project: mod_cluster
> Issue Type: Bug
> Reporter: Radoslav Husar
> Assignee: Radoslav Husar
>
> Update of the original effort for choosing documentation platform [1].
> Problem:
> * Documentation is out of date because its painful to edit.
> * Too many obstacles to contribute to documentation (difficult format, unclear where, need accounts, doesn't render immediately)
> Additional/updated requirements:
> * standardized on AsciiDocs
> * readers/users are provided with a link to update the documentation on github, submit PR, merge
> * automatically built and automatically deployed -- live within 1-2 minutes
> [1] https://developer.jboss.org/wiki/ChoosingDocumentationPlatformForModcluster
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
6 years
[JBoss JIRA] (MODCLUSTER-645) Different handling of max-attempts parameter on Undertow and httpd implementation
by Radoslav Husar (JIRA)
[ https://issues.jboss.org/browse/MODCLUSTER-645?page=com.atlassian.jira.pl... ]
Radoslav Husar commented on MODCLUSTER-645:
-------------------------------------------
Closing this tracker now as the problems are reported and fixes merged/submitted in the correct projects.
> 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: Task
> Affects Versions: 1.3.5.Final
> Reporter: Jan Kašík
> Assignee: Radoslav Husar
> Priority: Critical
>
> 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)
6 years
[JBoss JIRA] (MODCLUSTER-645) Different handling of max-attempts parameter on Undertow and httpd implementation
by Radoslav Husar (JIRA)
[ https://issues.jboss.org/browse/MODCLUSTER-645?page=com.atlassian.jira.pl... ]
Radoslav Husar resolved MODCLUSTER-645.
---------------------------------------
Resolution: Done
> 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: Task
> Affects Versions: 1.3.5.Final
> Reporter: Jan Kašík
> Assignee: Radoslav Husar
> Priority: Critical
>
> 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)
6 years
[JBoss JIRA] (MODCLUSTER-645) Different handling of max-attempts parameter on Undertow and httpd implementation
by Radoslav Husar (JIRA)
[ https://issues.jboss.org/browse/MODCLUSTER-645?page=com.atlassian.jira.pl... ]
Radoslav Husar edited comment on MODCLUSTER-645 at 3/23/18 11:12 AM:
---------------------------------------------------------------------
There are no changes in mod_cluster for this, so converting this to a tracker for UNDERTOW-1315 and WFLY-10093. Undertow fixes the off by one problem, WildFly one fixes the incorrect descriptions.
was (Author: rhusar):
There are no changes in mod_cluster for this, so converting this to a tracker for UNDERTOW-1315 and WFLY (TBA).
> 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: Task
> Affects Versions: 1.3.5.Final
> Reporter: Jan Kašík
> Assignee: Radoslav Husar
> Priority: Critical
>
> 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)
6 years
[JBoss JIRA] (MODCLUSTER-645) Different handling of max-attempts parameter on Undertow and httpd implementation
by Radoslav Husar (JIRA)
[ https://issues.jboss.org/browse/MODCLUSTER-645?page=com.atlassian.jira.pl... ]
Radoslav Husar updated MODCLUSTER-645:
--------------------------------------
Priority: Critical (was: Major)
> 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: Task
> Affects Versions: 1.3.5.Final
> Reporter: Jan Kašík
> Assignee: Radoslav Husar
> Priority: Critical
>
> 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)
6 years
[JBoss JIRA] (MODCLUSTER-645) Different handling of max-attempts parameter on Undertow and httpd implementation
by Radoslav Husar (JIRA)
[ https://issues.jboss.org/browse/MODCLUSTER-645?page=com.atlassian.jira.pl... ]
Radoslav Husar updated MODCLUSTER-645:
--------------------------------------
Issue Type: Task (was: Bug)
There are no changes in mod_cluster for this, so converting this to a tracker for UNDERTOW-1315 and WFLY (TBA).
> 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: Task
> 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)
6 years
[JBoss JIRA] (MODCLUSTER-645) Different handling of max-attempts parameter on Undertow and httpd implementation
by Radoslav Husar (JIRA)
[ https://issues.jboss.org/browse/MODCLUSTER-645?page=com.atlassian.jira.pl... ]
Radoslav Husar commented on MODCLUSTER-645:
-------------------------------------------
Actually, this is probably just bug in Undertow implementation how it understands max-attempts received in MCMP message.
{code:java}
@Override
public int getMaxRetries() {
...
return balancer.getMaxattempts() - 1;
}
{code}
> 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)
6 years
[JBoss JIRA] (MODCLUSTER-645) Different handling of max-attempts parameter on Undertow and httpd implementation
by Radoslav Husar (JIRA)
[ https://issues.jboss.org/browse/MODCLUSTER-645?page=com.atlassian.jira.pl... ]
Radoslav Husar edited comment on MODCLUSTER-645 at 3/22/18 8:24 AM:
--------------------------------------------------------------------
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.
was (Author: rhusar):
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)
6 years