November 2016 - mod_cluster-issues

[JBoss JIRA] (MODCLUSTER-553) Failover targets should be chosen deterministically

by Michal Karm Babacek (JIRA)

Michal Karm Babacek created MODCLUSTER-553: ---------------------------------------------- Summary: Failover targets should be chosen deterministically Key: MODCLUSTER-553 URL: https://issues.jboss.org/browse/MODCLUSTER-553 Project: mod_cluster Issue Type: Bug Components: Native (httpd modules) Affects Versions: 1.2.13.Final, 1.3.5.Final Reporter: Michal Karm Babacek Assignee: Paul Ferraro Fix For: 2.0.0.Alpha1, 1.2.14.Final, 1.3.6.Final Under the following conditions: 1. A request arrives for a session with an unknown route 2. A request arrives for a session with a known route in an error state, or if the intended worker is unresponsive and needs to failover ... the failover target must be chosen in a deterministic way. This is meant to mitigate the situation where concurrent requests failover to different nodes and cause cluster-wide contention for the session. Given a consistent ordering of workers (e.g. lexographically), the failover target should be chosen by something like: hash code of session id % active worker count. -- This message was sent by Atlassian JIRA (v7.2.3#72005)

7 years, 5 months

1
0
0 / 0

[JBoss JIRA] (MODCLUSTER-550) Failover targets should be chosen deterministically

by Paul Ferraro (JIRA)

[ https://issues.jboss.org/browse/MODCLUSTER-550?page=com.atlassian.jira.pl... ] Paul Ferraro commented on MODCLUSTER-550: ----------------------------------------- [~dmehra] This fix is not applicable to EAP - only to EWS. > Failover targets should be chosen deterministically > --------------------------------------------------- > > Key: MODCLUSTER-550 > URL: https://issues.jboss.org/browse/MODCLUSTER-550 > Project: mod_cluster > Issue Type: Bug > Components: Native (httpd modules) > Affects Versions: 1.2.13.Final, 1.3.5.Final > Reporter: Paul Ferraro > Assignee: Paul Ferraro > Fix For: 2.0.0.Alpha1, 1.2.14.Final, 1.3.6.Final > > > Under the following conditions: > 1. A request arrives for a session with an unknown route > 2. A request arrives for a session with a known route in an error state, or if the intended worker is unresponsive and needs to failover > ... the failover target must be chosen in a deterministic way. This is meant to mitigate the situation where concurrent requests failover to different nodes and cause cluster-wide contention for the session. Given a consistent ordering of workers (e.g. lexographically), the failover target should be chosen by something like: hash code of session id % active worker count. -- This message was sent by Atlassian JIRA (v7.2.3#72005)

7 years, 5 months

1
0
0 / 0

[JBoss JIRA] (MODCLUSTER-552) [GSS](7.1.0) Failover targets should be chosen deterministically

by Brad Maxwell (JIRA)

Brad Maxwell created MODCLUSTER-552: --------------------------------------- Summary: [GSS](7.1.0) Failover targets should be chosen deterministically Key: MODCLUSTER-552 URL: https://issues.jboss.org/browse/MODCLUSTER-552 Project: mod_cluster Issue Type: Bug Components: Native (httpd modules) Affects Versions: 1.2.13.Final, 1.3.5.Final Reporter: Brad Maxwell Assignee: Paul Ferraro Fix For: 2.0.0.Alpha1, 1.2.14.Final, 1.3.6.Final Under the following conditions: 1. A request arrives for a session with an unknown route 2. A request arrives for a session with a known route in an error state, or if the intended worker is unresponsive and needs to failover ... the failover target must be chosen in a deterministic way. This is meant to mitigate the situation where concurrent requests failover to different nodes and cause cluster-wide contention for the session. Given a consistent ordering of workers (e.g. lexographically), the failover target should be chosen by something like: hash code of session id % active worker count. -- This message was sent by Atlassian JIRA (v7.2.3#72005)

7 years, 5 months

1
0
0 / 0

[JBoss JIRA] (MODCLUSTER-505) ProxyErrorOverride=On causes workers in error state after 500 errors

by RH Bugzilla Integration (JIRA)

[ https://issues.jboss.org/browse/MODCLUSTER-505?page=com.atlassian.jira.pl... ] RH Bugzilla Integration commented on MODCLUSTER-505: ---------------------------------------------------- errata-xmlrpc <errata-xmlrpc(a)redhat.com> changed the Status of [bug 1391517|https://bugzilla.redhat.com/show_bug.cgi?id=1391517] from RELEASE_PENDING to CLOSED > ProxyErrorOverride=On causes workers in error state after 500 errors > --------------------------------------------------------------------- > > Key: MODCLUSTER-505 > URL: https://issues.jboss.org/browse/MODCLUSTER-505 > Project: mod_cluster > Issue Type: Bug > Components: Native (httpd modules) > Affects Versions: 1.3.2.Final, 1.2.12.Final > Reporter: Aaron Ogburn > Assignee: Jean-Frederic Clere > Fix For: 1.2.14.Final, 1.3.5.Final > > > When a VirtualHost uses ProxyPass to proxy traffic to the backend and uses ProxyErrorOverride to host custom error pages on Apache httpd side, when the backend replies with a 50x error code mod_proxy/mod_cluster marks that worker as down, breaking session stickiness. This behaviour is quite similar to have failonstatus=500 for example. -- This message was sent by Atlassian JIRA (v7.2.3#72005)

7 years, 5 months

1
0
0 / 0

[JBoss JIRA] (MODCLUSTER-522) Memory leak in processing MCMP, wrong apr pool used for allocation

by Michal Karm Babacek (JIRA)

[ https://issues.jboss.org/browse/MODCLUSTER-522?page=com.atlassian.jira.pl... ] Michal Karm Babacek commented on MODCLUSTER-522: ------------------------------------------------ Hi, [~lfinetto], we are in a process of rebuilding release infrastructure. If Fedora RPMs are good enough for you, the update will be ready this evening GMT+1. Other platforms like Solaris and Windows will be packaged next week in a slightly limited matrix than it used to be, i.e. "just": Windows 64bit, Solaris 11 Intel 64bit and Solaris 11 SPARC 64bit. If you have time to play with it and test right now, just tell me your platform and I will whip out a test build for it here and now. Cheers -K- > Memory leak in processing MCMP, wrong apr pool used for allocation > ------------------------------------------------------------------ > > Key: MODCLUSTER-522 > URL: https://issues.jboss.org/browse/MODCLUSTER-522 > Project: mod_cluster > Issue Type: Bug > Components: Native (httpd modules) > Affects Versions: 1.3.1.Final, 2.0.0.Alpha1 > Environment: Solaris 10 x86_64, RHEL 6, Fedora 24, httpd 2.4.6, httpd 2.4.20 > Reporter: Michal Karm Babacek > Assignee: Jean-Frederic Clere > Priority: Critical > Fix For: 1.3.5.Final > > Attachments: mod_cluster-mem.jpg, mod_cluster-mem1.jpg > > > There seems to be a wrong apr pool used for processing certain MCMP commands. We should use short life span pools for immediate processing and server-lifetime pools only for really persistent configuration. In the current state, with 20+ tomcat workers (1 alias and 1 context each) and virtually no client requests, we could see slow, but steady growth of heap allocated memory. > TODO: Investigate the offending logic, make sure we ain't using long-lived pools for immediate processing. > Originally discovered by: [~j_sykora] and [~jmsantuci] > Illustrative memory overview - with constant number of Tomcats: > -- This message was sent by Atlassian JIRA (v7.2.3#72005)

7 years, 5 months

1
0
0 / 0

[JBoss JIRA] (MODCLUSTER-522) Memory leak in processing MCMP, wrong apr pool used for allocation

by Lorenzo Finetto (JIRA)

[ https://issues.jboss.org/browse/MODCLUSTER-522?page=com.atlassian.jira.pl... ] Lorenzo Finetto commented on MODCLUSTER-522: -------------------------------------------- Hi Team. Where can I download the 1.3.5 final version? I have this issue and I would like to solve it with this version. Thank you > Memory leak in processing MCMP, wrong apr pool used for allocation > ------------------------------------------------------------------ > > Key: MODCLUSTER-522 > URL: https://issues.jboss.org/browse/MODCLUSTER-522 > Project: mod_cluster > Issue Type: Bug > Components: Native (httpd modules) > Affects Versions: 1.3.1.Final, 2.0.0.Alpha1 > Environment: Solaris 10 x86_64, RHEL 6, Fedora 24, httpd 2.4.6, httpd 2.4.20 > Reporter: Michal Karm Babacek > Assignee: Jean-Frederic Clere > Priority: Critical > Fix For: 1.3.5.Final > > Attachments: mod_cluster-mem.jpg, mod_cluster-mem1.jpg > > > There seems to be a wrong apr pool used for processing certain MCMP commands. We should use short life span pools for immediate processing and server-lifetime pools only for really persistent configuration. In the current state, with 20+ tomcat workers (1 alias and 1 context each) and virtually no client requests, we could see slow, but steady growth of heap allocated memory. > TODO: Investigate the offending logic, make sure we ain't using long-lived pools for immediate processing. > Originally discovered by: [~j_sykora] and [~jmsantuci] > Illustrative memory overview - with constant number of Tomcats: > -- This message was sent by Atlassian JIRA (v7.2.3#72005)

7 years, 5 months

1
0
0 / 0

[JBoss JIRA] (MODCLUSTER-550) Failover targets should be chosen deterministically

by RH Bugzilla Integration (JIRA)

[ https://issues.jboss.org/browse/MODCLUSTER-550?page=com.atlassian.jira.pl... ] RH Bugzilla Integration updated MODCLUSTER-550: ----------------------------------------------- Bugzilla References: https://bugzilla.redhat.com/show_bug.cgi?id=1394057 (was: https://bugzilla.redhat.com/1389093) Bugzilla Update: Perform > Failover targets should be chosen deterministically > --------------------------------------------------- > > Key: MODCLUSTER-550 > URL: https://issues.jboss.org/browse/MODCLUSTER-550 > Project: mod_cluster > Issue Type: Bug > Components: Native (httpd modules) > Affects Versions: 1.2.13.Final, 1.3.5.Final > Reporter: Paul Ferraro > Assignee: Paul Ferraro > Fix For: 2.0.0.Alpha1, 1.2.14.Final, 1.3.6.Final > > > Under the following conditions: > 1. A request arrives for a session with an unknown route > 2. A request arrives for a session with a known route in an error state, or if the intended worker is unresponsive and needs to failover > ... the failover target must be chosen in a deterministic way. This is meant to mitigate the situation where concurrent requests failover to different nodes and cause cluster-wide contention for the session. Given a consistent ordering of workers (e.g. lexographically), the failover target should be chosen by something like: hash code of session id % active worker count. -- This message was sent by Atlassian JIRA (v7.2.3#72005)

7 years, 5 months

1
0
0 / 0

[JBoss JIRA] (MODCLUSTER-505) ProxyErrorOverride=On causes workers in error state after 500 errors

by RH Bugzilla Integration (JIRA)

[ https://issues.jboss.org/browse/MODCLUSTER-505?page=com.atlassian.jira.pl... ] RH Bugzilla Integration commented on MODCLUSTER-505: ---------------------------------------------------- errata-xmlrpc <errata-xmlrpc(a)redhat.com> changed the Status of [bug 1310582|https://bugzilla.redhat.com/show_bug.cgi?id=1310582] from ON_QA to VERIFIED > ProxyErrorOverride=On causes workers in error state after 500 errors > --------------------------------------------------------------------- > > Key: MODCLUSTER-505 > URL: https://issues.jboss.org/browse/MODCLUSTER-505 > Project: mod_cluster > Issue Type: Bug > Components: Native (httpd modules) > Affects Versions: 1.3.2.Final, 1.2.12.Final > Reporter: Aaron Ogburn > Assignee: Jean-Frederic Clere > Fix For: 1.2.14.Final, 1.3.5.Final > > > When a VirtualHost uses ProxyPass to proxy traffic to the backend and uses ProxyErrorOverride to host custom error pages on Apache httpd side, when the backend replies with a 50x error code mod_proxy/mod_cluster marks that worker as down, breaking session stickiness. This behaviour is quite similar to have failonstatus=500 for example. -- This message was sent by Atlassian JIRA (v7.2.3#72005)

7 years, 5 months

1
0
0 / 0

[JBoss JIRA] (MODCLUSTER-550) Failover targets should be chosen deterministically

by Paul Ferraro (JIRA)

[ https://issues.jboss.org/browse/MODCLUSTER-550?page=com.atlassian.jira.pl... ] Paul Ferraro updated MODCLUSTER-550: ------------------------------------ Bugzilla References: https://bugzilla.redhat.com/1389093 > Failover targets should be chosen deterministically > --------------------------------------------------- > > Key: MODCLUSTER-550 > URL: https://issues.jboss.org/browse/MODCLUSTER-550 > Project: mod_cluster > Issue Type: Bug > Components: Native (httpd modules) > Affects Versions: 1.2.13.Final, 1.3.5.Final > Reporter: Paul Ferraro > Assignee: Paul Ferraro > Fix For: 2.0.0.Alpha1, 1.2.14.Final, 1.3.6.Final > > > Under the following conditions: > 1. A request arrives for a session with an unknown route > 2. A request arrives for a session with a known route in an error state, or if the intended worker is unresponsive and needs to failover > ... the failover target must be chosen in a deterministic way. This is meant to mitigate the situation where concurrent requests failover to different nodes and cause cluster-wide contention for the session. Given a consistent ordering of workers (e.g. lexographically), the failover target should be chosen by something like: hash code of session id % active worker count. -- This message was sent by Atlassian JIRA (v7.2.3#72005)

7 years, 5 months

1
0
0 / 0

[JBoss JIRA] (MODCLUSTER-550) Failover targets should be chosen deterministically

by Radoslav Husar (JIRA)

[ https://issues.jboss.org/browse/MODCLUSTER-550?page=com.atlassian.jira.pl... ] Radoslav Husar updated MODCLUSTER-550: -------------------------------------- Status: Resolved (was: Pull Request Sent) Resolution: Done > Failover targets should be chosen deterministically > --------------------------------------------------- > > Key: MODCLUSTER-550 > URL: https://issues.jboss.org/browse/MODCLUSTER-550 > Project: mod_cluster > Issue Type: Bug > Components: Native (httpd modules) > Affects Versions: 1.2.13.Final, 1.3.5.Final > Reporter: Paul Ferraro > Assignee: Paul Ferraro > Fix For: 2.0.0.Alpha1, 1.2.14.Final, 1.3.6.Final > > > Under the following conditions: > 1. A request arrives for a session with an unknown route > 2. A request arrives for a session with a known route in an error state, or if the intended worker is unresponsive and needs to failover > ... the failover target must be chosen in a deterministic way. This is meant to mitigate the situation where concurrent requests failover to different nodes and cause cluster-wide contention for the session. Given a consistent ordering of workers (e.g. lexographically), the failover target should be chosen by something like: hash code of session id % active worker count. -- This message was sent by Atlassian JIRA (v7.2.3#72005)

7 years, 5 months

1
0
0 / 0

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

mod_cluster-issues November 2016