June 2016 - mod_cluster-issues - Jboss List Archives

[JBoss JIRA] (MODCLUSTER-363) Rather unsettling warnings in Solaris build logs

by Radoslav Husar (JIRA)

[ https://issues.jboss.org/browse/MODCLUSTER-363?page=com.atlassian.jira.pl... ] Radoslav Husar updated MODCLUSTER-363: -------------------------------------- Fix Version/s: 1.2.14.Final (was: 1.2.13.Final) > Rather unsettling warnings in Solaris build logs > ------------------------------------------------ > > Key: MODCLUSTER-363 > URL: https://issues.jboss.org/browse/MODCLUSTER-363 > Project: mod_cluster > Issue Type: Bug > Affects Versions: 1.2.6.Final > Environment: Solaris sparc, x86 > Reporter: Michal Karm Babacek > Assignee: Jean-Frederic Clere > Fix For: 1.2.14.Final > > > Configure and compilation steps e.g. in these builds: [mod_cluster-solaris10-sparc64|https://jenkins.mw.lab.eng.bos.redhat.com/h...] and [mod_cluster-solaris10-x86|https://jenkins.mw.lab.eng.bos.redhat.com/hudso...]. > Bugspotter: [~vtunka] -- This message was sent by Atlassian JIRA (v6.4.11#64026)

7 years, 10 months

1
0
0 / 0

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

by Radoslav Husar (JIRA)

[ https://issues.jboss.org/browse/MODCLUSTER-391?page=com.atlassian.jira.pl... ] Radoslav Husar updated MODCLUSTER-391: -------------------------------------- Fix Version/s: 1.2.14.Final (was: 1.2.13.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.3.3.Final, 1.2.14.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 (v6.4.11#64026)

7 years, 10 months

1
0
0 / 0

[JBoss JIRA] (MODCLUSTER-416) mod_cluster Connected count shows improper inflation

by Radoslav Husar (JIRA)

[ https://issues.jboss.org/browse/MODCLUSTER-416?page=com.atlassian.jira.pl... ] Radoslav Husar updated MODCLUSTER-416: -------------------------------------- Fix Version/s: 1.2.14.Final (was: 1.2.13.Final) > mod_cluster Connected count shows improper inflation > ---------------------------------------------------- > > Key: MODCLUSTER-416 > URL: https://issues.jboss.org/browse/MODCLUSTER-416 > Project: mod_cluster > Issue Type: Bug > Components: Native (httpd modules) > Affects Versions: 1.2.9.Final > Reporter: Aaron Ogburn > Assignee: Jean-Frederic Clere > Fix For: 1.3.3.Final, 1.2.14.Final > > > The mod_cluster connected count (a proxy_worker's busy attribute) shows improper inflation. With load stopped, non-zero values have still been seen through the mod_cluster-manager page and INFO MCMP responses. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

7 years, 10 months

1
0
0 / 0

[JBoss JIRA] (MODCLUSTER-430) CreateBalancers behave the same with option 0 or 2

by Radoslav Husar (JIRA)

[ https://issues.jboss.org/browse/MODCLUSTER-430?page=com.atlassian.jira.pl... ] Radoslav Husar updated MODCLUSTER-430: -------------------------------------- Fix Version/s: 1.2.14.Final (was: 1.2.13.Final) > CreateBalancers behave the same with option 0 or 2 > -------------------------------------------------- > > Key: MODCLUSTER-430 > URL: https://issues.jboss.org/browse/MODCLUSTER-430 > Project: mod_cluster > Issue Type: Bug > Components: Native (httpd modules) > Affects Versions: 1.3.0.Final, 1.2.9.Final > Environment: RHEL 6.4.0 > Apache HTTPD 2.4.10 > JBoss 6.1.1 > Mod_cluster 1.3.0 Final > Reporter: John Jerome > Assignee: Michal Karm Babacek > Fix For: 1.3.3.Final, 1.2.14.Final > > > The directive CreateBalancers with directive 0 or 2 creates the balancers on all httpd vhosts. > With option 2, the balancers should be created on the main server only, not in the vhosts. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

7 years, 10 months

1
0
0 / 0

[JBoss JIRA] (MODCLUSTER-401) EnableOptions and SSL configuration

by Radoslav Husar (JIRA)

[ https://issues.jboss.org/browse/MODCLUSTER-401?page=com.atlassian.jira.pl... ] Radoslav Husar updated MODCLUSTER-401: -------------------------------------- Fix Version/s: 1.2.14.Final (was: 1.2.13.Final) > EnableOptions and SSL configuration > ----------------------------------- > > Key: MODCLUSTER-401 > URL: https://issues.jboss.org/browse/MODCLUSTER-401 > Project: mod_cluster > Issue Type: Bug > Affects Versions: 1.2.8.Final > Environment: HP-UX Apache HTTP Server 2.2.15, RHEL Apache HTTP Server 2.2.22, perhaps platform independent... > Reporter: Michal Karm Babacek > Assignee: Jean-Frederic Clere > Fix For: 1.2.14.Final > > > As a follow up on MODCLUSTER-400 and a documentation effort for *EnableOptions* logic, I tried to add {{EnableOptions}} to the configuration so as to allow for a "cping/cpong" emulation of the famous AJP feature. > With the following {{mod_cluster.conf / httpd.conf}} (standalone-ha.xml being the same as in MODCLUSTER-400's description): > {code} > +++ > Listen 10.16.92.191:2081 > +++ > MemManagerFile "/hell/workspace/hpws22/apache/cache/mod_cluster" > ServerName 10.16.92.191:2081 > <IfModule manager_module> > Listen 10.16.92.191:8745 > LogLevel debug > <VirtualHost 10.16.92.191:8745> > ServerName 10.16.92.191:8745 > <Directory /> > Order deny,allow > Deny from all > Allow from all > </Directory> > KeepAliveTimeout 60 > MaxKeepAliveRequests 0 > ServerAdvertise on > AdvertiseFrequency 5 > ManagerBalancerName qacluster > AdvertiseGroup 224.0.3.47:23364 > EnableOptions > EnableMCPMReceive > SSLEngine on > SSLProtocol all -SSLv2 -SSLv3 > SSLCipherSuite "EECDH+ECDSA+AESGCM EECDH+aRSA+AESGCM EECDH+ECDSA+SHA384 EECDH+ECDSA+SHA256 EECDH+aRSA+SHA384 EECDH+aRSA+SHA256 EECDH+aRSA+RC4 EECDH EDH+aRSA RC4 !aNULL !eNULL !LOW !3DES !MD5 !EXP !PSK !SRP !DSS" > SSLHonorCipherOrder on > SSLCertificateFile /vault/server.crt > SSLCertificateKeyFile /vault/server.key > SSLCACertificateFile /vault/myca.crt > SSLProxyEngine On > SSLVerifyDepth 10 > <Location /mcm> > SetHandler mod_cluster-manager > Order deny,allow > Deny from all > Allow from all > </Location> > </VirtualHost> > </IfModule> > {code} > one gets this [^hp-ux_error_log-EnableOptions.zip] log: > {code} > [debug] mod_proxy_cluster.c(1223): http_cping_cpong: received HTTP/1.1 200 OK > [debug] mod_proxy_cluster.c(1223): http_cping_cpong: received Server: Apache-Coyote/1.1 > [debug] mod_proxy_cluster.c(1223): http_cping_cpong: received Allow: GET, HEAD, POST, PUT, DELETE, TRACE, OPTIONS > [debug] mod_proxy_cluster.c(1223): http_cping_cpong: received Content-Length: 0 > [debug] mod_proxy_cluster.c(1223): http_cping_cpong: received Date: Fri, 02 May 2014 17:22:46 GMT > [debug] mod_proxy_cluster.c(1223): http_cping_cpong: received Connection: close > [debug] mod_proxy_cluster.c(1239): http_cping_cpong: Done > [debug] proxy_util.c(2047): proxy: https: has released connection for (10.16.92.191) > [debug] mod_manager.c(2666): manager_handler STATUS OK > [debug] proxy_util.c(2029): proxy: https: has acquired connection for (10.16.92.191) > [debug] proxy_util.c(2085): proxy: connecting https://10.16.92.191:8645/ to 10.16.92.191:8645 > [debug] proxy_util.c(2211): proxy: connected / to 10.16.92.191:8645 > [debug] proxy_util.c(2462): proxy: https: fam 2 socket created to connect to 10.16.92.191 > [debug] mod_proxy_cluster.c(1384): proxy_cluster_try_pingpong: connected to backend > [error] [client 10.16.92.191] SSL Proxy requested for 10.16.92.191:2081 but not enabled [Hint: SSLProxyEngine] > [error] proxy: https: failed to enable ssl support for 10.16.92.191:8645 (10.16.92.191) > [debug] proxy_util.c(2047): proxy: https: has released connection for (10.16.92.191) > {code} > Why is the JBoss EAP residing on {{10.16.92.191:8645}} trying to request SSL Proxy on the virtual host {{10.16.92.191:2081}}? The result is {{Status: NOTOK}} on mod_cluser manager console. > I tried to remove that {{10.16.92.191:2081}}, so as the {{10.16.92.191:8745}} is the only one ([^hp-ux_error_log-EnableOptions-single-vhost.zip]): > {code} > - Listen 10.16.92.191:2081 > - ServerName 10.16.92.191:2081 > {code} > The result is a funny trial to request a proxy for the boxe's actual hostname and port 80 *no one* (netstat) is even listening on: > {code} > [debug] mod_proxy_cluster.c(1223): http_cping_cpong: received HTTP/1.1 200 OK > [debug] mod_proxy_cluster.c(1223): http_cping_cpong: received Server: Apache-Coyote/1.1 > [debug] mod_proxy_cluster.c(1223): http_cping_cpong: received Allow: GET, HEAD, POST, PUT, DELETE, TRACE, OPTIONS > [debug] mod_proxy_cluster.c(1223): http_cping_cpong: received Content-Length: 0 > [debug] mod_proxy_cluster.c(1223): http_cping_cpong: received Date: Fri, 02 May 2014 17:39:33 GMT > [debug] mod_proxy_cluster.c(1223): http_cping_cpong: received Connection: close > [debug] mod_proxy_cluster.c(1239): http_cping_cpong: Done > [debug] proxy_util.c(2047): proxy: https: has released connection for (10.16.92.191) > [debug] mod_manager.c(2666): manager_handler STATUS OK > [debug] proxy_util.c(2029): proxy: https: has acquired connection for (10.16.92.191) > [debug] proxy_util.c(2085): proxy: connecting https://10.16.92.191:8645/ to 10.16.92.191:8645 > [debug] proxy_util.c(2211): proxy: connected / to 10.16.92.191:8645 > [debug] proxy_util.c(2462): proxy: https: fam 2 socket created to connect to 10.16.92.191 > [debug] mod_proxy_cluster.c(1384): proxy_cluster_try_pingpong: connected to backend > [error] [client 10.16.92.191] SSL Proxy requested for eap-perf-hpux-03.mw.lab.eng.bos.redhat.com:80 but not enabled [Hint: SSLProxyEngine] > [error] proxy: https: failed to enable ssl support for 10.16.92.191:8645 (10.16.92.191) > [debug] proxy_util.c(2047): proxy: https: has released connection for (10.16.92.191) > {code} > I tried to add: {{RequestHeader set Front-End-Https "On"}} to the configuration without any luck. > Finally, I replicated the SSL configuration *outside* the VirtualHost: > {code} > MemManagerFile "/hell/workspace/hpws22/apache/cache/mod_cluster" > Listen 10.16.92.191:2081 > ServerName 10.16.92.191:2081 > SSLEngine on > SSLProtocol all -SSLv2 -SSLv3 > SSLCipherSuite "EECDH+ECDSA+AESGCM EECDH+aRSA+AESGCM EECDH+ECDSA+SHA384 EECDH+ECDSA+SHA256 EECDH+aRSA+SHA384 EECDH+aRSA+SHA256 EECDH+aRSA+RC4 EECDH EDH+aRSA RC4 !aNULL !eNULL !LOW !3DES !MD5 !EXP !PSK !S RP !DSS" > SSLHonorCipherOrder on > SSLCertificateFile /vault/server.crt > SSLCertificateKeyFile /vault/server.key > SSLCACertificateFile /vault/myca.crt > SSLProxyEngine On > SSLVerifyDepth 10 > <IfModule manager_module> > +++ the same as above +++ > </IfModule> > {code} > This configuration fixed the aforementioned {{failed to enable ssl support}} *and* actually helped to workaround the MODCLUSTER-400: (log: [^hp-ux_error_log-EnableOptions-SSL_everywhere.zip]) > {code} > Fri, May 2, 2014 02:23:44 PM Request URI: /clusterbench/requestinfo > Headers: {host=10.16.92.191:8645, user-agent=curl/7.30.0, accept=*/*, cookie=JSESSIONID=2hC9ax9LGYDvQZtH0RXdBimf.jboss-eap-6.3-2, x-forwarded-for=10.16.92.191, x-forwarded-host=10.16.92.191:8745, x-forwarded-server=10.16.92.191, connection=Keep-Alive} > Host header: 10.16.92.191:8645 > Character encoding: null > JVM route: jboss-eap-6.3-2 > Session ID: 2hC9ax9LGYDvQZtH0RXdBimf.jboss-eap-6.3-2 > Session isNew: false > Fri, May 2, 2014 02:23:47 PM Request URI: /clusterbench/requestinfo > Headers: {host=10.16.92.191:8645, user-agent=curl/7.30.0, accept=*/*, cookie=JSESSIONID=2hC9ax9LGYDvQZtH0RXdBimf.jboss-eap-6.3-2, x-forwarded-for=10.16.92.191, x-forwarded-host=10.16.92.191:8745, x-forwarded-server=10.16.92.191, connection=Keep-Alive} > Host header: 10.16.92.191:8645 > Character encoding: null > JVM route: jboss-eap-6.3-2 > Session ID: 2hC9ax9LGYDvQZtH0RXdBimf.jboss-eap-6.3-2 > Session isNew: false > -- stop jboss-eap-6.3-2 -- (the same behavior with jvm kill) -- > Fri, May 2, 2014 02:23:50 PM Request URI: /clusterbench/requestinfo > Headers: {host=10.16.92.191:8544, user-agent=curl/7.30.0, accept=*/*, cookie=JSESSIONID=2hC9ax9LGYDvQZtH0RXdBimf.jboss-eap-6.3-2, x-forwarded-for=10.16.92.191, x-forwarded-host=10.16.92.191:8745, x-forwarded-server=10.16.92.191, connection=Keep-Alive} > Host header: 10.16.92.191:8544 > Character encoding: null > JVM route: jboss-eap-6.3 > Session ID: 2hC9ax9LGYDvQZtH0RXdBimf.jboss-eap-6.3 > Session isNew: false > Fri, May 2, 2014 02:23:53 PM Request URI: /clusterbench/requestinfo > Headers: {host=10.16.92.191:8544, user-agent=curl/7.30.0, accept=*/*, cookie=JSESSIONID=2hC9ax9LGYDvQZtH0RXdBimf.jboss-eap-6.3, x-forwarded-for=10.16.92.191, x-forwarded-host=10.16.92.191:8745, x-forwarded-server=10.16.92.191, connection=Keep-Alive} > Host header: 10.16.92.191:8544 > Character encoding: null > JVM route: jboss-eap-6.3 > Session ID: 2hC9ax9LGYDvQZtH0RXdBimf.jboss-eap-6.3 > Session isNew: false > Fri, May 2, 2014 02:23:56 PM Request URI: /clusterbench/requestinfo > Headers: {host=10.16.92.191:8544, user-agent=curl/7.30.0, accept=*/*, cookie=JSESSIONID=2hC9ax9LGYDvQZtH0RXdBimf.jboss-eap-6.3, x-forwarded-for=10.16.92.191, x-forwarded-host=10.16.92.191:8745, x-forwarded-server=10.16.92.191, connection=Keep-Alive} > Host header: 10.16.92.191:8544 > Character encoding: null > JVM route: jboss-eap-6.3 > Session ID: 2hC9ax9LGYDvQZtH0RXdBimf.jboss-eap-6.3 > Session isNew: false > {code} > Why isn't the {{10.16.92.191:8745}} enough? Is it a configuration error or a ProxyPass/SSL integration bug? -- This message was sent by Atlassian JIRA (v6.4.11#64026)

7 years, 10 months

1
0
0 / 0

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

by Radoslav Husar (JIRA)

[ https://issues.jboss.org/browse/MODCLUSTER-505?page=com.atlassian.jira.pl... ] Radoslav Husar updated MODCLUSTER-505: -------------------------------------- Fix Version/s: 1.2.14.Final (was: 1.2.13.Final) > 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.3.3.Final, 1.2.14.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 (v6.4.11#64026)

7 years, 10 months

1
0
0 / 0

[JBoss JIRA] (MODCLUSTER-448) mod_cluster crashes apache thread if multiple nodes report the same AJP connect string

by Radoslav Husar (JIRA)

[ https://issues.jboss.org/browse/MODCLUSTER-448?page=com.atlassian.jira.pl... ] Radoslav Husar updated MODCLUSTER-448: -------------------------------------- Fix Version/s: 1.2.14.Final (was: 1.2.13.Final) > mod_cluster crashes apache thread if multiple nodes report the same AJP connect string > -------------------------------------------------------------------------------------- > > Key: MODCLUSTER-448 > URL: https://issues.jboss.org/browse/MODCLUSTER-448 > Project: mod_cluster > Issue Type: Feature Request > Components: Native (httpd modules) > Affects Versions: 1.2.6.Final > Reporter: Michal Karm Babacek > Assignee: Michal Karm Babacek > Fix For: 1.3.3.Final, 1.2.14.Final > > > Reported on behalf of [Toby Murray|https://github.com/ToeBee]: > Tracking issue #[138|https://github.com/modcluster/mod_cluster/issues/138] > Let's carry on with any discussion here, on JIRA... -- This message was sent by Atlassian JIRA (v6.4.11#64026)

7 years, 10 months

1
0
0 / 0

[JBoss JIRA] (MODCLUSTER-437) Misleading mod_cluster error log : All workers are in error state

by Radoslav Husar (JIRA)

[ https://issues.jboss.org/browse/MODCLUSTER-437?page=com.atlassian.jira.pl... ] Radoslav Husar updated MODCLUSTER-437: -------------------------------------- Fix Version/s: 1.2.14.Final (was: 1.2.13.Final) > Misleading mod_cluster error log : All workers are in error state > ----------------------------------------------------------------- > > Key: MODCLUSTER-437 > URL: https://issues.jboss.org/browse/MODCLUSTER-437 > Project: mod_cluster > Issue Type: Enhancement > Affects Versions: 1.2.9.Final, 1.3.1.Alpha2 > Reporter: Michal Karm Babacek > Assignee: Jean-Frederic Clere > Priority: Minor > Fix For: 1.2.14.Final > > > See [BZ 995345|https://bugzilla.redhat.com/show_bug.cgi?id=995345] for details. > IMHO this is a minor usability fix that might help users to better understand the log, but it's not anything crucial. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

7 years, 10 months

1
0
0 / 0

[JBoss JIRA] (MODCLUSTER-507) Worker22 on RHEL-7 [mod_cluster segfaults]

by Radoslav Husar (JIRA)

[ https://issues.jboss.org/browse/MODCLUSTER-507?page=com.atlassian.jira.pl... ] Radoslav Husar updated MODCLUSTER-507: -------------------------------------- Fix Version/s: 1.2.14.Final (was: 1.2.13.Final) > Worker22 on RHEL-7 [mod_cluster segfaults] > ------------------------------------------ > > Key: MODCLUSTER-507 > URL: https://issues.jboss.org/browse/MODCLUSTER-507 > Project: mod_cluster > Issue Type: Bug > Components: Native (httpd modules) > Affects Versions: 1.2.9.Final > Environment: mod_cluster-1.3.2 *IS NOT* affected any more > Reporter: Michal Karm Babacek > Assignee: Jean-Frederic Clere > Fix For: 1.2.14.Final > > > Long term (days) running on httpd 2.2.26, with *worker* MPM on RHEL 7 x86_64, random segfaults in mod_manager. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

7 years, 10 months

1
0
0 / 0

[JBoss JIRA] (MODCLUSTER-506) SegFault due to corrupt nodestatsmem

by Radoslav Husar (JIRA)

[ https://issues.jboss.org/browse/MODCLUSTER-506?page=com.atlassian.jira.pl... ] Radoslav Husar updated MODCLUSTER-506: -------------------------------------- Fix Version/s: 1.2.14.Final (was: 1.2.13.Final) > SegFault due to corrupt nodestatsmem > ------------------------------------ > > Key: MODCLUSTER-506 > URL: https://issues.jboss.org/browse/MODCLUSTER-506 > Project: mod_cluster > Issue Type: Bug > Components: Native (httpd modules) > Affects Versions: 1.2.12.Final > Environment: _redhat_2.ep6.el6.x86_64 > Reporter: Michal Karm Babacek > Assignee: Michal Karm Babacek > Priority: Critical > Fix For: 1.2.14.Final > > > See linked bugzillas, corrupted nodestatsmem. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

7 years, 10 months

1
0
0 / 0

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

mod_cluster-issues June 2016