January 2014 - mod_cluster-issues

[JBoss JIRA] (MODCLUSTER-381) [Patch] Stability and portability issues in native code

by Jean-Frederic Clere (JIRA)

[ https://issues.jboss.org/browse/MODCLUSTER-381?page=com.atlassian.jira.pl... ] Jean-Frederic Clere commented on MODCLUSTER-381: ------------------------------------------------ Good stuff I will merge it when I have cycles. > [Patch] Stability and portability issues in native code > ------------------------------------------------------- > > Key: MODCLUSTER-381 > URL: https://issues.jboss.org/browse/MODCLUSTER-381 > Project: mod_cluster > Issue Type: Patch > Affects Versions: 1.2.6.Final > Reporter: Jan Andres > Assignee: Jean-Frederic Clere > Attachments: mod_cluster-1.2.6-20140109.diff > > > Hi, > Please find attached a patch for some issues I came across while deploying mod_cluster for Apache on Solaris/SPARC. The patch applies to the 1.2.6 release and addresses a total of 3 issues: > 1. A memory leak in add_balancers_workers(). The current code will allocate new memory from the config pool for the balancer's "sticky" parameter on each update but throw away the pointer (thus losing memory) if the value generated equals the balancer's current value. The patch changes this to first do the apr_psprintf() from a temporary pool and only apr_pstrdup() this temporary string into the config pool in case it differs from the old value and actually needs to be updated. > 2. Memory alignment issues. Some parts of the code use custom memory alignment logic and will generally align memory blocks to a multiple of sizeof(void*). This poses a problem on some architectures such a 64-bit SPARC CPU running a "32-bit application" which really means the process has a 32-bit memory space (i.e. sizeof(void*) is 4), but can still use native 64-bit instructions to operate on data. On SPARC and some other architectures, these instructions require 8-byte data alignment and will lead to a Bus error if this is not observed. The patch replaces the custom alignment logic by invocations of APR_ALIGN_DEFAULT() which also makes the code somewhat more concise and readable. > 3. Heap corruption issues on process exit, sometimes resulting in core dumps, because mod_proxy_cluster's watchdog thread never terminates and continues to run while the main thread is already freeing up resources and destroying all the memory pools. The patch adds a mechanism to signal the watchdog thread to terminate and wait for it to exit prior to the freeing of the memory resources. This mechanism is invoked via a pre-cleanup hook on the config pool. > Regards, > Jan -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira

10 years, 11 months

1
0
0 / 0

[JBoss JIRA] (MODCLUSTER-365) Reset MCMPs are sent to all available proxies

by RH Bugzilla Integration (JIRA)

[ https://issues.jboss.org/browse/MODCLUSTER-365?page=com.atlassian.jira.pl... ] RH Bugzilla Integration commented on MODCLUSTER-365: ---------------------------------------------------- Jimmy Wilson <jawilson(a)redhat.com> changed the Status of [bug 1050221|https://bugzilla.redhat.com/show_bug.cgi?id=1050221] from POST to NEW > Reset MCMPs are sent to all available proxies > --------------------------------------------- > > Key: MODCLUSTER-365 > URL: https://issues.jboss.org/browse/MODCLUSTER-365 > Project: mod_cluster > Issue Type: Bug > Affects Versions: 1.2.6.Final > Environment: -JBoss Enterprise Application Platform (EAP) 6.1.1 > Reporter: Aaron Ogburn > Assignee: Jean-Frederic Clere > Labels: mod_cluster > Fix For: 1.2.7.Final, 1.3.0.Alpha2 > > > Consider a JBoss server with multiple httpd servers defined in its proxy-list. If one of those httpd servers goes down and then comes back up, then reset MCMPs (CONFIG, ENABLE-APP) would be sent to the restarted httpd proxy but needlessly to all other proxies as well. This is because DefaultMCMPHandler.status just calls sendRequests, which will send to all proxies by design. > This has negative implications if auto-enable-contexts is set to false and can break desired behavior. Reproducer steps detail the issue introduced in that scenario. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira

10 years, 11 months

1
0
0 / 0

[JBoss JIRA] (MODCLUSTER-381) [Patch] Stability and portability issues in native code

by Jan Andres (JIRA)

[ https://issues.jboss.org/browse/MODCLUSTER-381?page=com.atlassian.jira.pl... ] Jan Andres updated MODCLUSTER-381: ---------------------------------- Attachment: mod_cluster-1.2.6-20140109.diff > [Patch] Stability and portability issues in native code > ------------------------------------------------------- > > Key: MODCLUSTER-381 > URL: https://issues.jboss.org/browse/MODCLUSTER-381 > Project: mod_cluster > Issue Type: Patch > Affects Versions: 1.2.6.Final > Reporter: Jan Andres > Assignee: Jean-Frederic Clere > Attachments: mod_cluster-1.2.6-20140109.diff > > > Hi, > Please find attached a patch for some issues I came across while deploying mod_cluster for Apache on Solaris/SPARC. The patch applies to the 1.2.6 release and addresses a total of 3 issues: > 1. A memory leak in add_balancers_workers(). The current code will allocate new memory from the config pool for the balancer's "sticky" parameter on each update but throw away the pointer (thus losing memory) if the value generated equals the balancer's current value. The patch changes this to first do the apr_psprintf() from a temporary pool and only apr_pstrdup() this temporary string into the config pool in case it differs from the old value and actually needs to be updated. > 2. Memory alignment issues. Some parts of the code use custom memory alignment logic and will generally align memory blocks to a multiple of sizeof(void*). This poses a problem on some architectures such a 64-bit SPARC CPU running a "32-bit application" which really means the process has a 32-bit memory space (i.e. sizeof(void*) is 4), but can still use native 64-bit instructions to operate on data. On SPARC and some other architectures, these instructions require 8-byte data alignment and will lead to a Bus error if this is not observed. The patch replaces the custom alignment logic by invocations of APR_ALIGN_DEFAULT() which also makes the code somewhat more concise and readable. > 3. Heap corruption issues on process exit, sometimes resulting in core dumps, because mod_proxy_cluster's watchdog thread never terminates and continues to run while the main thread is already freeing up resources and destroying all the memory pools. The patch adds a mechanism to signal the watchdog thread to terminate and wait for it to exit prior to the freeing of the memory resources. This mechanism is invoked via a pre-cleanup hook on the config pool. > Regards, > Jan -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira

10 years, 11 months

1
0
0 / 0

[JBoss JIRA] (MODCLUSTER-381) [Patch] Stability and portability issues in native code

by Jan Andres (JIRA)

Jan Andres created MODCLUSTER-381: ------------------------------------- Summary: [Patch] Stability and portability issues in native code Key: MODCLUSTER-381 URL: https://issues.jboss.org/browse/MODCLUSTER-381 Project: mod_cluster Issue Type: Patch Affects Versions: 1.2.6.Final Reporter: Jan Andres Assignee: Jean-Frederic Clere Attachments: mod_cluster-1.2.6-20140109.diff Hi, Please find attached a patch for some issues I came across while deploying mod_cluster for Apache on Solaris/SPARC. The patch applies to the 1.2.6 release and addresses a total of 3 issues: 1. A memory leak in add_balancers_workers(). The current code will allocate new memory from the config pool for the balancer's "sticky" parameter on each update but throw away the pointer (thus losing memory) if the value generated equals the balancer's current value. The patch changes this to first do the apr_psprintf() from a temporary pool and only apr_pstrdup() this temporary string into the config pool in case it differs from the old value and actually needs to be updated. 2. Memory alignment issues. Some parts of the code use custom memory alignment logic and will generally align memory blocks to a multiple of sizeof(void*). This poses a problem on some architectures such a 64-bit SPARC CPU running a "32-bit application" which really means the process has a 32-bit memory space (i.e. sizeof(void*) is 4), but can still use native 64-bit instructions to operate on data. On SPARC and some other architectures, these instructions require 8-byte data alignment and will lead to a Bus error if this is not observed. The patch replaces the custom alignment logic by invocations of APR_ALIGN_DEFAULT() which also makes the code somewhat more concise and readable. 3. Heap corruption issues on process exit, sometimes resulting in core dumps, because mod_proxy_cluster's watchdog thread never terminates and continues to run while the main thread is already freeing up resources and destroying all the memory pools. The patch adds a mechanism to signal the watchdog thread to terminate and wait for it to exit prior to the freeing of the memory resources. This mechanism is invoked via a pre-cleanup hook on the config pool. Regards, Jan -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira

10 years, 11 months

1
0
0 / 0

[JBoss JIRA] (MODCLUSTER-365) Reset MCMPs are sent to all available proxies

by RH Bugzilla Integration (JIRA)

[ https://issues.jboss.org/browse/MODCLUSTER-365?page=com.atlassian.jira.pl... ] RH Bugzilla Integration commented on MODCLUSTER-365: ---------------------------------------------------- Brad Maxwell <bmaxwell(a)redhat.com> changed the Status of [bug 1050221|https://bugzilla.redhat.com/show_bug.cgi?id=1050221] from NEW to POST > Reset MCMPs are sent to all available proxies > --------------------------------------------- > > Key: MODCLUSTER-365 > URL: https://issues.jboss.org/browse/MODCLUSTER-365 > Project: mod_cluster > Issue Type: Bug > Affects Versions: 1.2.6.Final > Environment: -JBoss Enterprise Application Platform (EAP) 6.1.1 > Reporter: Aaron Ogburn > Assignee: Jean-Frederic Clere > Labels: mod_cluster > Fix For: 1.2.7.Final, 1.3.0.Alpha2 > > > Consider a JBoss server with multiple httpd servers defined in its proxy-list. If one of those httpd servers goes down and then comes back up, then reset MCMPs (CONFIG, ENABLE-APP) would be sent to the restarted httpd proxy but needlessly to all other proxies as well. This is because DefaultMCMPHandler.status just calls sendRequests, which will send to all proxies by design. > This has negative implications if auto-enable-contexts is set to false and can break desired behavior. Reproducer steps detail the issue introduced in that scenario. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira

10 years, 11 months

1
0
0 / 0

[JBoss JIRA] (MODCLUSTER-365) Reset MCMPs are sent to all available proxies

by RH Bugzilla Integration (JIRA)

[ https://issues.jboss.org/browse/MODCLUSTER-365?page=com.atlassian.jira.pl... ] RH Bugzilla Integration commented on MODCLUSTER-365: ---------------------------------------------------- Brad Maxwell <bmaxwell(a)redhat.com> changed the Status of [bug 1050223|https://bugzilla.redhat.com/show_bug.cgi?id=1050223] from NEW to POST > Reset MCMPs are sent to all available proxies > --------------------------------------------- > > Key: MODCLUSTER-365 > URL: https://issues.jboss.org/browse/MODCLUSTER-365 > Project: mod_cluster > Issue Type: Bug > Affects Versions: 1.2.6.Final > Environment: -JBoss Enterprise Application Platform (EAP) 6.1.1 > Reporter: Aaron Ogburn > Assignee: Jean-Frederic Clere > Labels: mod_cluster > Fix For: 1.2.7.Final, 1.3.0.Alpha2 > > > Consider a JBoss server with multiple httpd servers defined in its proxy-list. If one of those httpd servers goes down and then comes back up, then reset MCMPs (CONFIG, ENABLE-APP) would be sent to the restarted httpd proxy but needlessly to all other proxies as well. This is because DefaultMCMPHandler.status just calls sendRequests, which will send to all proxies by design. > This has negative implications if auto-enable-contexts is set to false and can break desired behavior. Reproducer steps detail the issue introduced in that scenario. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira

10 years, 11 months

1
0
0 / 0

[JBoss JIRA] (MODCLUSTER-168) mod_cluster should use hostname provided in address instead a IP address

by Jean-Frederic Clere (JIRA)

[ https://issues.jboss.org/browse/MODCLUSTER-168?page=com.atlassian.jira.pl... ] Jean-Frederic Clere updated MODCLUSTER-168: ------------------------------------------- Fix Version/s: 1.2.8.Final (was: 1.2.7.Final) > mod_cluster should use hostname provided in address instead a IP address > ------------------------------------------------------------------------ > > Key: MODCLUSTER-168 > URL: https://issues.jboss.org/browse/MODCLUSTER-168 > Project: mod_cluster > Issue Type: Feature Request > Affects Versions: 1.1.0.CR3 > Environment: any > Reporter: Jean-Frederic Clere > Assignee: Paul Ferraro > Fix For: 1.2.8.Final > > > The CONFIG message contains something like: > JVMRoute=51ec121e-2976-3d75-bfd9-9e662bbb4bcd&Host=10.33.144.3&Port=8009&Type=ajp > Even if the Connector is defined like: > <Connector port="8009" address= "jfcpc" protocol="AJP/1.3" redirectPort="8443" /> > There are 2 ways to fix: > - Use the String (Change the Connector.java in mod_cluster). > - Use parameters.put("Host", connector.getAddress().getHostName()); when building the CONFIG message. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira

10 years, 11 months

1
0
0 / 0

[JBoss JIRA] (MODCLUSTER-329) Add ModClusterService methods to obtain status of a context

by Jean-Frederic Clere (JIRA)

[ https://issues.jboss.org/browse/MODCLUSTER-329?page=com.atlassian.jira.pl... ] Jean-Frederic Clere updated MODCLUSTER-329: ------------------------------------------- Fix Version/s: 1.2.8.Final (was: 1.2.7.Final) > Add ModClusterService methods to obtain status of a context > ----------------------------------------------------------- > > Key: MODCLUSTER-329 > URL: https://issues.jboss.org/browse/MODCLUSTER-329 > Project: mod_cluster > Issue Type: Feature Request > Affects Versions: 1.2.3.Final > Reporter: Paul Ferraro > Assignee: Paul Ferraro > Fix For: 1.2.8.Final > > > In order for AS7 management operations like "stop-context" to figure out how to properly rollback, they need to know the initial status of the context. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira

10 years, 11 months

1
0
0 / 0

[JBoss JIRA] (MODCLUSTER-330) Demo webapp doesn't work on AS7

by Jean-Frederic Clere (JIRA)

[ https://issues.jboss.org/browse/MODCLUSTER-330?page=com.atlassian.jira.pl... ] Jean-Frederic Clere updated MODCLUSTER-330: ------------------------------------------- Fix Version/s: 1.2.8.Final (was: 1.2.7.Final) > Demo webapp doesn't work on AS7 > ------------------------------- > > Key: MODCLUSTER-330 > URL: https://issues.jboss.org/browse/MODCLUSTER-330 > Project: mod_cluster > Issue Type: Bug > Affects Versions: 1.2.3.Final > Reporter: Paul Ferraro > Assignee: Paul Ferraro > Fix For: 1.2.8.Final > > > The demo webapp contains references to org.apache.catalina classes, but does not properly include these dependencies in its MANIFEST.MF. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira

10 years, 11 months

1
0
0 / 0

[JBoss JIRA] (MODCLUSTER-359) stickysession not working with httpd-2.4.6 / mod_cluster-1.2.5.Final

by Jean-Frederic Clere (JIRA)

[ https://issues.jboss.org/browse/MODCLUSTER-359?page=com.atlassian.jira.pl... ] Jean-Frederic Clere updated MODCLUSTER-359: ------------------------------------------- Fix Version/s: 1.2.8.Final (was: 1.2.7.Final) > stickysession not working with httpd-2.4.6 / mod_cluster-1.2.5.Final > --------------------------------------------------------------------- > > Key: MODCLUSTER-359 > URL: https://issues.jboss.org/browse/MODCLUSTER-359 > Project: mod_cluster > Issue Type: Bug > Affects Versions: 1.2.5.Final, 1.2.6.Final > Environment: OS. SLES-11-SP1 x86_64 > Reporter: Marco Danti > Assignee: Jean-Frederic Clere > Labels: httpd, mod_cluster, stickysession > Fix For: 1.2.8.Final > > Attachments: MODCLUSTER-359-debug-info.tar.gz, tses.war > > > Setup: HTTPD configured as reverse proxy / load balancer for two instances of JBOSS-AS-7.2.0.Final running in HA configuration on two separate nodes. > Consider the following configuration (defined inside my virtual hosts) > > <Proxy balancer://mycluster> > ProxySet stickysession=JSESSIONID|jsessionid > </Proxy> > On httpd-2.2.24 / mod_cluster-1.2.0.Final it shows the following behaviour: > - 'stickysession' is working as expected > After upgrading to httpd-2.4.6/mod_cluster-1.2.5.Final things are worse: > - 'stickysession' is ignored and any client request gets dispatched alternatively > to each one of the two JBoss servers (exactly as if lbmethod=byrequest were defined) > As a final consideration, I read in the docs that stickysession should be enabled by default in mod_cluster anyway, but that is not the case for me. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira

10 years, 11 months

1
0
0 / 0

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

mod_cluster-issues January 2014