March 2018 - mod_cluster-issues - Jboss List Archives

[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... ] Work on MODCLUSTER-645 started by Radoslav Husar. ------------------------------------------------- > 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, 9 months

1
0
0 / 0

[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: ------------------------------------------- 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, 9 months

1
0
0 / 0

[JBoss JIRA] (MODCLUSTER-645) Different handling of max-attempts parameter on Undertow and httpd implementation

by Jean-Frederic Clere (JIRA)

[ https://issues.jboss.org/browse/MODCLUSTER-645?page=com.atlassian.jira.pl... ] Jean-Frederic Clere reassigned MODCLUSTER-645: ---------------------------------------------- Assignee: Radoslav Husar (was: Jean-Frederic Clere) > 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, 9 months

1
0
0 / 0

[JBoss JIRA] (MODCLUSTER-645) Different handling of max-attempts parameter on Undertow and httpd implementation

by Jan Kašík (JIRA)

[ https://issues.jboss.org/browse/MODCLUSTER-645?page=com.atlassian.jira.pl... ] Jan Kašík commented on MODCLUSTER-645: -------------------------------------- [~jfclere] Hi! Any news on this? > 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: Jean-Frederic Clere > > 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, 9 months

1
0
0 / 0

[JBoss JIRA] (MODCLUSTER-647) Upgrade jboss-logging-processor to 2.1.0.Final

by Radoslav Husar (JIRA)

[ https://issues.jboss.org/browse/MODCLUSTER-647?page=com.atlassian.jira.pl... ] Radoslav Husar commented on MODCLUSTER-647: ------------------------------------------- Just to note, this is only for compilation runs with JDK8 and higher. > Upgrade jboss-logging-processor to 2.1.0.Final > ---------------------------------------------- > > Key: MODCLUSTER-647 > URL: https://issues.jboss.org/browse/MODCLUSTER-647 > Project: mod_cluster > Issue Type: Component Upgrade > Components: Core & Container Integration (Java) > Reporter: Radoslav Husar > Assignee: Radoslav Husar > Fix For: 2.0.0.Alpha1 > > > Needed to support JDK11 EA > Changelog: https://github.com/jboss-logging/jboss-logging-tools/tree/2.1.0.Final -- This message was sent by Atlassian JIRA (v7.5.0#75005)

6 years, 9 months

1
0
0 / 0

[JBoss JIRA] (MODCLUSTER-647) Upgrade jboss-logging-processor to 2.1.0.Final

by Radoslav Husar (JIRA)

[ https://issues.jboss.org/browse/MODCLUSTER-647?page=com.atlassian.jira.pl... ] Radoslav Husar updated MODCLUSTER-647: -------------------------------------- Status: Resolved (was: Pull Request Sent) Resolution: Done > Upgrade jboss-logging-processor to 2.1.0.Final > ---------------------------------------------- > > Key: MODCLUSTER-647 > URL: https://issues.jboss.org/browse/MODCLUSTER-647 > Project: mod_cluster > Issue Type: Component Upgrade > Components: Core & Container Integration (Java) > Reporter: Radoslav Husar > Assignee: Radoslav Husar > Fix For: 2.0.0.Alpha1 > > > Needed to support JDK11 EA > Changelog: https://github.com/jboss-logging/jboss-logging-tools/tree/2.1.0.Final -- This message was sent by Atlassian JIRA (v7.5.0#75005)

6 years, 9 months

1
0
0 / 0

[JBoss JIRA] (MODCLUSTER-651) Upgrade jboss-parent to 26

by Radoslav Husar (JIRA)

[ https://issues.jboss.org/browse/MODCLUSTER-651?page=com.atlassian.jira.pl... ] Radoslav Husar updated MODCLUSTER-651: -------------------------------------- Status: Resolved (was: Pull Request Sent) Resolution: Done > Upgrade jboss-parent to 26 > -------------------------- > > Key: MODCLUSTER-651 > URL: https://issues.jboss.org/browse/MODCLUSTER-651 > Project: mod_cluster > Issue Type: Component Upgrade > Components: Core & Container Integration (Java) > Reporter: Radoslav Husar > Assignee: Radoslav Husar > Fix For: 2.0.0.Alpha1 > > > Changelog > https://github.com/jboss/jboss-parent-pom/tree/jboss-parent-26 -- This message was sent by Atlassian JIRA (v7.5.0#75005)

6 years, 9 months

1
0
0 / 0

[JBoss JIRA] (MODCLUSTER-648) Upgrade jboss-logging to 3.3.2.Final

by Radoslav Husar (JIRA)

[ https://issues.jboss.org/browse/MODCLUSTER-648?page=com.atlassian.jira.pl... ] Radoslav Husar updated MODCLUSTER-648: -------------------------------------- Status: Resolved (was: Pull Request Sent) Resolution: Done > Upgrade jboss-logging to 3.3.2.Final > ------------------------------------ > > Key: MODCLUSTER-648 > URL: https://issues.jboss.org/browse/MODCLUSTER-648 > Project: mod_cluster > Issue Type: Component Upgrade > Components: Core & Container Integration (Java) > Reporter: Radoslav Husar > Assignee: Radoslav Husar > Fix For: 2.0.0.Alpha1 > > > Changelog https://github.com/jboss-logging/jboss-logging/tree/3.3.2.Final -- This message was sent by Atlassian JIRA (v7.5.0#75005)

6 years, 9 months

1
0
0 / 0

[JBoss JIRA] (MODCLUSTER-650) Travis CI: Expand build matrix to JDK10 and JDK11

by Radoslav Husar (JIRA)

[ https://issues.jboss.org/browse/MODCLUSTER-650?page=com.atlassian.jira.pl... ] Radoslav Husar updated MODCLUSTER-650: -------------------------------------- Status: Resolved (was: Pull Request Sent) Resolution: Done > Travis CI: Expand build matrix to JDK10 and JDK11 > ------------------------------------------------- > > Key: MODCLUSTER-650 > URL: https://issues.jboss.org/browse/MODCLUSTER-650 > Project: mod_cluster > Issue Type: Task > Components: CI & Packaging > Reporter: Radoslav Husar > Assignee: Radoslav Husar > Fix For: 2.0.0.Alpha1 > > > To support new JDKs we need more flexibility than Travis CI support out of box, e.g. open/oracle jdk10/jdk11. -- This message was sent by Atlassian JIRA (v7.5.0#75005)

6 years, 9 months

1
0
0 / 0

[JBoss JIRA] (MODCLUSTER-649) Support JDK11 build build 11-ea+3

by Radoslav Husar (JIRA)

[ https://issues.jboss.org/browse/MODCLUSTER-649?page=com.atlassian.jira.pl... ] Radoslav Husar updated MODCLUSTER-649: -------------------------------------- Status: Resolved (was: Pull Request Sent) Resolution: Done > Support JDK11 build build 11-ea+3 > --------------------------------- > > Key: MODCLUSTER-649 > URL: https://issues.jboss.org/browse/MODCLUSTER-649 > Project: mod_cluster > Issue Type: Task > Components: Core & Container Integration (Java) > Reporter: Radoslav Husar > Assignee: Radoslav Husar > Fix For: 2.0.0.Alpha1 > > -- This message was sent by Atlassian JIRA (v7.5.0#75005)

6 years, 9 months

1
0
0 / 0

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

mod_cluster-issues March 2018