October 2016 - mod_cluster-issues

[JBoss JIRA] (MODCLUSTER-415) Drop support for HP-UX older than HP-UX 11v3 (Itanium 64)

by Jean-Frederic Clere (JIRA)

[ https://issues.jboss.org/browse/MODCLUSTER-415?page=com.atlassian.jira.pl... ] Jean-Frederic Clere updated MODCLUSTER-415: ------------------------------------------- Fix Version/s: 1.3.6.Final (was: 1.3.5.Final) > Drop support for HP-UX older than HP-UX 11v3 (Itanium 64) > --------------------------------------------------------- > > Key: MODCLUSTER-415 > URL: https://issues.jboss.org/browse/MODCLUSTER-415 > Project: mod_cluster > Issue Type: Feature Request > Components: Documentation & Demos, Native (httpd modules) > Reporter: Radoslav Husar > Assignee: Jean-Frederic Clere > Fix For: 1.3.6.Final > > > As per https://access.redhat.com/site/articles/111663 we can drop support for HP-UX older than HP-UX 11v3 (Itanium 64). -- This message was sent by Atlassian JIRA (v7.2.2#72004)

7 years, 6 months

1
0
0 / 0

[JBoss JIRA] (MODCLUSTER-460) Silence superflous "MODCLUSTER000033: Failed to interrupt socket reception" on shutdown

by Jean-Frederic Clere (JIRA)

[ https://issues.jboss.org/browse/MODCLUSTER-460?page=com.atlassian.jira.pl... ] Jean-Frederic Clere updated MODCLUSTER-460: ------------------------------------------- Fix Version/s: 1.3.6.Final (was: 1.3.5.Final) > Silence superflous "MODCLUSTER000033: Failed to interrupt socket reception" on shutdown > --------------------------------------------------------------------------------------- > > Key: MODCLUSTER-460 > URL: https://issues.jboss.org/browse/MODCLUSTER-460 > Project: mod_cluster > Issue Type: Bug > Components: Core & Container Integration (Java) > Affects Versions: 1.3.1.Final > Reporter: Radoslav Husar > Assignee: Radoslav Husar > Priority: Minor > Fix For: 1.3.6.Final > > > This seems to be caused by the legacy code in mod_cluster, which could instead make use of interruptible channels introduced since JDK 1.4. Simpler option would be log this message onto debug. -- This message was sent by Atlassian JIRA (v7.2.2#72004)

7 years, 6 months

1
0
0 / 0

[JBoss JIRA] (MODCLUSTER-501) mod_proxy_cluster crash when using BalancerMember

by Jean-Frederic Clere (JIRA)

[ https://issues.jboss.org/browse/MODCLUSTER-501?page=com.atlassian.jira.pl... ] Jean-Frederic Clere updated MODCLUSTER-501: ------------------------------------------- Fix Version/s: 1.3.6.Final (was: 1.3.5.Final) > mod_proxy_cluster crash when using BalancerMember > ------------------------------------------------- > > Key: MODCLUSTER-501 > URL: https://issues.jboss.org/browse/MODCLUSTER-501 > Project: mod_cluster > Issue Type: Bug > Components: Native (httpd modules) > Affects Versions: 1.3.1.Final > Environment: o.s.:: CentOS Linux release 7.2.1511 > httpd 2.4.6 > mod cluster 1.3.1 final > Reporter: Paolo Lutterotti > Assignee: Michal Karm Babacek > Fix For: 1.3.6.Final > > Attachments: httpd.conf, modules.txt, vhost.conf, vhost.conf > > > Hello, > I'm experiencing an issue very similar to https://issues.jboss.org/browse/MODCLUSTER-356 > When I try to use a BalancerMember directive, I get a segmentation fault, caused at line https://github.com/modcluster/mod_cluster/blob/1.3.1.Final/native/mod_pro... > I tried to remove directives from the virtual host, but the issue persists until there is at least one ProxyPass using a balancer defined with BalancerMember. I attach a .conf file where I put all of the configurations involved in the issue and which is causing the crash. > If I put a check at line 2223, there are no more segmentations, but a 503 caused by mod_proxy_cluster.c(2332): proxy: byrequests balancer FAILED > Thanks, > Paolo -- This message was sent by Atlassian JIRA (v7.2.2#72004)

7 years, 6 months

1
0
0 / 0

[JBoss JIRA] (MODCLUSTER-508) &balancer->name[11], because of default: balancer://mycluster: Change magic number 11 to something meaningful

by Jean-Frederic Clere (JIRA)

[ https://issues.jboss.org/browse/MODCLUSTER-508?page=com.atlassian.jira.pl... ] Jean-Frederic Clere updated MODCLUSTER-508: ------------------------------------------- Fix Version/s: 1.3.6.Final (was: 1.3.5.Final) > &balancer->name[11], because of default: balancer://mycluster: Change magic number 11 to something meaningful > ------------------------------------------------------------------------------------------------------------- > > Key: MODCLUSTER-508 > URL: https://issues.jboss.org/browse/MODCLUSTER-508 > Project: mod_cluster > Issue Type: Enhancement > Components: Native (httpd modules) > Affects Versions: 1.3.2.Final, 1.2.13.Final > Reporter: Michal Karm Babacek > Assignee: Michal Karm Babacek > Priority: Trivial > Fix For: 1.3.6.Final > > > While we compare balancers URL char by char, we start at index 11, because > the default beginning: {{balancer://}} is always there. It would be nice to change 11 to a named constant so as it is clear why it's 11 without debugger :) -- This message was sent by Atlassian JIRA (v7.2.2#72004)

7 years, 6 months

1
0
0 / 0

[JBoss JIRA] (MODCLUSTER-391) mod_cluster and mod_proxy integration

by Jean-Frederic Clere (JIRA)

[ https://issues.jboss.org/browse/MODCLUSTER-391?page=com.atlassian.jira.pl... ] Jean-Frederic Clere updated MODCLUSTER-391: ------------------------------------------- Fix Version/s: 1.3.6.Final (was: 1.3.5.Final) > mod_cluster and mod_proxy integration > ------------------------------------- > > Key: MODCLUSTER-391 > URL: https://issues.jboss.org/browse/MODCLUSTER-391 > Project: mod_cluster > Issue Type: Bug > Affects Versions: 1.2.6.Final > Environment: All platforms we build mod_cluster for. > Reporter: Michal Karm Babacek > Assignee: Jean-Frederic Clere > Labels: native_libraries > Fix For: 1.2.14.Final, 1.3.6.Final > > Attachments: error_log, mod_cluster.conf, mod_proxy.conf, standalone-ha.xml > > > This Jira encapsulates all concerns regarding mod_cluster - mod_proxy integration. For instance, while basic {{ProxyPass}} settings work just fine, e.g. serving some files on {{/static}} from the Apache HTTP itself: > {code} > ProxyPassMatch ^/static/ ! > ProxyPass / balancer://qacluster stickysession=JSESSIONID|jsessionid nofailover=on > ProxyPassReverse / balancer://qacluster > ProxyPreserveHost on > {code} > there are more complex setups, involving {{BalancerMember}} configurations, that do not work as expected. In the following example, one wanted to have {{/clusterbench}} application managed by mod_cluster, dynamically, while at the same time, in a different VirtualHost, having {{/tses}} application handled by manually created mod_proxy balancer settings. > Attached [^mod_cluster.conf], [^mod_proxy.conf], [^standalone-ha.xml](modcluster subsystem element only) and [^error_log]. > The aforementioned setup resulted in: > |HTTP 200|(From worker)|http://10.16.88.19:8847/clusterbench/requestinfo/|OK|(/)| > |HTTP 404|(From httpd)|http://10.16.88.19:8847/tses/session.jsp|Expected fail|(/)| > |HTTP 503|(From httpd)|http://10.16.88.19:2182/tses/session.jsp|Unexpected fail|(x)| -- This message was sent by Atlassian JIRA (v7.2.2#72004)

7 years, 6 months

1
0
0 / 0

[JBoss JIRA] (MODCLUSTER-526) SIGSEGV in remove_workers_node (mod_proxy_cluster.so) when using LoadBalancingGroup

by Jean-Frederic Clere (JIRA)

[ https://issues.jboss.org/browse/MODCLUSTER-526?page=com.atlassian.jira.pl... ] Jean-Frederic Clere updated MODCLUSTER-526: ------------------------------------------- Fix Version/s: 1.3.6.Final (was: 1.3.5.Final) > SIGSEGV in remove_workers_node (mod_proxy_cluster.so) when using LoadBalancingGroup > ----------------------------------------------------------------------------------- > > Key: MODCLUSTER-526 > URL: https://issues.jboss.org/browse/MODCLUSTER-526 > Project: mod_cluster > Issue Type: Bug > Components: Native (httpd modules) > Affects Versions: 1.3.3.Final > Environment: Fedora 20, x86_64, httpd 2.4.20 mpm_event > Reporter: Michal Karm Babacek > Assignee: Michal Karm Babacek > Priority: Blocker > Fix For: 1.3.6.Final > > > h3. Setup > * 3 tomcats > * 2 load balancing groups > * 1 request every 3 seconds (no load at all) > * shutdown and kill of various nodes > * no later than third kill/start iteration causes SIGSEGV > h3. SIGSEGV > {code} > #if AP_MODULE_MAGIC_AT_LEAST(20101223,1) > /* Here that is tricky the worker needs shared memory but we don't and CONFIG will reset it */ > helper->index = 0; /* mark it removed */ > worker->s = helper->shared; > crash---> memcpy(worker->s, stat, sizeof(proxy_worker_shared)); > #else > worker->id = 0; /* mark it removed */ > #endif > {code} > h3. Behavior > {code} > 957 helper = (proxy_cluster_helper *) worker->context; > 961 if (helper) { > 962 i = helper->count_active; > 963 } > 968 if (i == 0) { > 971 proxy_worker_shared *stat = worker->s; > 972 proxy_cluster_helper *helper = (proxy_cluster_helper *) worker->context; > {code} > At this point, {{helper->shared}} points to a {{proxy_worker_shared}} structure that appears to be properly filled. > {code} > 999 if (worker->cp->pool) { > 1000 apr_pool_destroy(worker->cp->pool); > 1001 worker->cp->pool = NULL; > 1002 } > {code} > Regardless of the aforementioned block being there or nor (stuffed after 1010), > {{helper->shared}} suddenly points to {{NULL}}. > {code} > 1008 helper->index = 0; > 1009 worker->s = helper->shared; > {code} > Above assignment makes {{worker->s}} pointing to NULL. > {code} > 1010 memcpy(worker->s, stat, sizeof(proxy_worker_shared)); > {code} > And here we go :( > IMHO, _other thread_ already cleared that memory and nulled the pointer, because it absolutely doesn't happen if > I run 1 process and 1 thread. > The [workaround that prevents the core|https://github.com/modcluster/mod_cluster/pull/207] looks like this: > {code} > if (helper->shared) { > worker->s = helper->shared; > memcpy(worker->s, stat, sizeof(proxy_worker_shared)); > } > {code} > h3. How do we fix it? > Any ideas? [~jfclere] -- This message was sent by Atlassian JIRA (v7.2.2#72004)

7 years, 6 months

1
0
0 / 0

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

by Jean-Frederic Clere (JIRA)

[ https://issues.jboss.org/browse/MODCLUSTER-505?page=com.atlassian.jira.pl... ] Jean-Frederic Clere resolved MODCLUSTER-505. -------------------------------------------- Resolution: Done > 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.2#72004)

7 years, 6 months

1
0
0 / 0

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

by Jean-Frederic Clere (JIRA)

[ https://issues.jboss.org/browse/MODCLUSTER-522?page=com.atlassian.jira.pl... ] Jean-Frederic Clere updated MODCLUSTER-522: ------------------------------------------- Status: Resolved (was: Pull Request Sent) Resolution: Done > 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.2#72004)

7 years, 6 months

1
0
0 / 0

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

by Jean-Frederic Clere (JIRA)

[ https://issues.jboss.org/browse/MODCLUSTER-522?page=com.atlassian.jira.pl... ] Jean-Frederic Clere updated MODCLUSTER-522: ------------------------------------------- Fix Version/s: 1.3.5.Final > 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.2#72004)

7 years, 6 months

1
0
0 / 0

[JBoss JIRA] (MODCLUSTER-540) ManagerBalancerName variable is lowercased

by Jean-Frederic Clere (JIRA)

[ https://issues.jboss.org/browse/MODCLUSTER-540?page=com.atlassian.jira.pl... ] Jean-Frederic Clere closed MODCLUSTER-540. ------------------------------------------ Resolution: Rejected > ManagerBalancerName variable is lowercased > ------------------------------------------ > > Key: MODCLUSTER-540 > URL: https://issues.jboss.org/browse/MODCLUSTER-540 > Project: mod_cluster > Issue Type: Bug > Affects Versions: 1.3.3.Final > Reporter: Bogdan Sikora > Assignee: Michal Karm Babacek > > Documentation > {noformat} > 3.5.8. ManagerBalancerName > ManagerBalancerName: That is the name of balancer to use when the JBoss AS/JBossWeb/Tomcat doesn't provide a balancer name. > Default: mycluster > {noformat} > Issue: > Apache Httpd (2.4.23-ER1) did not recognize ManagerBalancerName uppercase letters and is turning whole name to lowercase. If worker passes balancer name then is correctly used as documentation suggest and even with uppercase letters. > Reproduce: > 1. Set up balancer (httpd) with worker (for example EAP-7, do not set Balancer variable) > 2. Set ManagerBalancerName to QA-bAlAnCeR in mod_cluster.conf > 3. Start everything and access mod_cluster status page > 4. Look for Balancer variable under your worker, should be cAmeLcAse but isn't > Workaround: > Set balancer name in each worker, as documentation says it will override variable set in mod_cluster.conf (ManagerBalancerName) > Verbose: > Httpd debug node join part > {noformat} > 08:13:22.058 [INFO] RESPONSE: <!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2 Final//EN"> > <html><head> > <title>Mod_cluster Status</title> > </head><body> > <h1>mod_cluster/1.3.3.Final</h1><a href="/mcm?nonce=2cfb1542-913e-11e6-9142-9fb646370036&refresh=10">Auto Refresh</a> <a href="/mcm?nonce=2cfb1542-913e-11e6-9142-9fb646370036&Cmd=DUMP&Range=ALL">show DUMP output</a> <a href="/mcm?nonce=2cfb1542-913e-11e6-9142-9fb646370036&Cmd=INFO&Range=ALL">show INFO output</a> > <h1> Node jboss-eap-7.1 (ajp://192.168.122.88:8009): </h1> > <a href="/mcm?nonce=2cfb1542-913e-11e6-9142-9fb646370036&Cmd=ENABLE-APP&Range=NODE&JVMRoute=jboss-eap-7.1">Enable Contexts</a> <a href="/mcm?nonce=2cfb1542-913e-11e6-9142-9fb646370036&Cmd=DISABLE-APP&Range=NODE&JVMRoute=jboss-eap-7.1">Disable Contexts</a> <a href="/mcm?nonce=2cfb1542-913e-11e6-9142-9fb646370036&Cmd=STOP-APP&Range=NODE&JVMRoute=jboss-eap-7.1">Stop Contexts</a><br/> > Balancer:qa-balancer,LBGroup: ,Flushpackets: Off,Flushwait: 10000,Ping: 10000000,Smax: 2,Ttl: 60000000,Status: OK,Elected: 0,Read: 0,Transferred: 0,Connected: 0,Load: 1 > <h2> Virtual Host 1:</h2><h3>Contexts:</h3><pre>/clusterbench, Status: ENABLED Request: 0 <a href="/mcm?nonce=2cfb1542-913e-11e6-9142-9fb646370036&Cmd=DISABLE-APP&Range=CONTEXT&JVMRoute=jboss-eap-7.1&Alias=default-host&Context=/clusterbench">Disable</a> <a href="/mcm?nonce=2cfb1542-913e-11e6-9142-9fb646370036&Cmd=STOP-APP&Range=CONTEXT&JVMRoute=jboss-eap-7.1&Alias=default-host&Context=/clusterbench">Stop</a> > </pre><h3>Aliases:</h3><pre>default-host > localhost > </pre></body></html> > {noformat} > {noformat} > [Thu Oct 13 08:12:04.337611 2016] [:debug] [pid 12216] mod_manager.c(3018): manager_handler CONFIG (/) processing: "JVMRoute=jboss-eap-7.1&Host=192.168.122.88&Maxattempts=1&Port=8009&StickySessionForce=No&Type=ajp&ping=10" > [Thu Oct 13 08:12:04.340202 2016] [:debug] [pid 12216] mod_manager.c(3068): manager_handler CONFIG OK > [Thu Oct 13 08:12:04.342416 2016] [:debug] [pid 12217] mod_manager.c(2302): manager_trans ENABLE-APP (/) > [Thu Oct 13 08:12:04.342499 2016] [authz_core:debug] [pid 12217] mod_authz_core.c(809): [client 192.168.122.88:54652] AH01626: authorization result of Require all granted: granted > [Thu Oct 13 08:12:04.342509 2016] [authz_core:debug] [pid 12217] mod_authz_core.c(809): [client 192.168.122.88:54652] AH01626: authorization result of <RequireAny>: granted > [Thu Oct 13 08:12:04.342576 2016] [:debug] [pid 12217] mod_proxy_cluster.c(1054): update_workers_node starting > [Thu Oct 13 08:12:04.343186 2016] [:debug] [pid 12217] mod_proxy_cluster.c(695): add_balancer_node: Create balancer balancer://qa-balancer > [Thu Oct 13 08:12:04.343243 2016] [:debug] [pid 12217] mod_proxy_cluster.c(293): Created: worker for ajp://192.168.122.88:8009 > [Thu Oct 13 08:12:04.343259 2016] [proxy:debug] [pid 12217] proxy_util.c(1779): AH00925: initializing worker ajp://192.168.122.88 shared > [Thu Oct 13 08:12:04.343262 2016] [proxy:debug] [pid 12217] proxy_util.c(1821): AH00927: initializing worker ajp://192.168.122.88 local > [Thu Oct 13 08:12:04.343279 2016] [proxy:debug] [pid 12217] proxy_util.c(1872): AH00931: initialized single connection worker in child 12217 for (192.168.122.88) > [Thu Oct 13 08:12:04.343288 2016] [:debug] [pid 12217] mod_proxy_cluster.c(293): Created: worker for ajp://192.168.122.88:8009 > [Thu Oct 13 08:12:04.343290 2016] [proxy:debug] [pid 12217] proxy_util.c(1774): AH00924: worker ajp://192.168.122.88 shared already initialized > [Thu Oct 13 08:12:04.343292 2016] [proxy:debug] [pid 12217] proxy_util.c(1821): AH00927: initializing worker ajp://192.168.122.88 local > [Thu Oct 13 08:12:04.343312 2016] [proxy:debug] [pid 12217] proxy_util.c(1872): AH00931: initialized single connection worker in child 12217 for (192.168.122.88) > [Thu Oct 13 08:12:04.343318 2016] [:debug] [pid 12217] mod_proxy_cluster.c(1066): update_workers_node done > {noformat} > Configuration (mod_cluster.conf) > {noformat} > <IfModule manager_module> > Listen 192.168.122.88:8747 > LogLevel debug > <VirtualHost 192.168.122.88:8747> > ServerName localhost.localdomain:8747 > <Directory /> > Require all granted > </Directory> > KeepAliveTimeout 60 > MaxKeepAliveRequests 0 > ServerAdvertise on > AdvertiseFrequency 5 > ManagerBalancerName QA-bAlAnCeR > AdvertiseGroup 224.0.5.88:23364 > AdvertiseBindAddress 192.168.122.88:23364 > EnableMCPMReceive > <Location /mcm> > SetHandler mod_cluster-manager > Require all granted > </Location> > </VirtualHost> > </IfModule> > {noformat} -- This message was sent by Atlassian JIRA (v7.2.2#72004)

7 years, 6 months

1
0
0 / 0

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

mod_cluster-issues October 2016