March 2020 - mod_cluster-issues - Jboss List Archives

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

by Jean-Frederic Clere (Jira)

[ https://issues.redhat.com/browse/MODCLUSTER-401?page=com.atlassian.jira.p... ] Jean-Frederic Clere closed MODCLUSTER-401. ------------------------------------------ Resolution: Rejected As explained in https://issues.redhat.com/browse/MODCLUSTER-401?focusedCommentId=12965378... it is a configuration error. > EnableOptions and SSL configuration > ----------------------------------- > > Key: MODCLUSTER-401 > URL: https://issues.redhat.com/browse/MODCLUSTER-401 > Project: mod_cluster > Issue Type: Bug > Components: Native (httpd modules) > 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 > Assignee: Jean-Frederic Clere > Priority: Major > 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 (v7.13.8#713008)

4 years, 1 month

1
0
0 / 0

[JBoss JIRA] (MODCLUSTER-527) Load Balancing logic can fail production environments

by Jean-Frederic Clere (Jira)

[ https://issues.redhat.com/browse/MODCLUSTER-527?page=com.atlassian.jira.p... ] Jean-Frederic Clere closed MODCLUSTER-527. ------------------------------------------ Resolution: Won't Fix > Load Balancing logic can fail production environments > ----------------------------------------------------- > > Key: MODCLUSTER-527 > URL: https://issues.redhat.com/browse/MODCLUSTER-527 > Project: mod_cluster > Issue Type: Bug > Components: Native (httpd modules) > Environment: > Reporter: Sean Cavanagh > Assignee: Jean-Frederic Clere > Priority: Major > > We suffered the same problem as MODCLUSTER-100 in our production environment. > If any balance pool sees 0 requests during 2*LBstatusRecalTime the next request will go to the first worker in the pool. If an application consistently sends requests at a rate less than 2*LBstatusRecalTime, then all requests will be sent to the same node, and _balancing will be completely broken_ > Less worrisome, but still not ideal, if one worker is more heavily balanced than the others (e.g. it's load factor has been manually set to '1' in order to offload it; a somewhat common practice), that worker will still get a session once every 2*LBstatusRecalTime. > I know it seems odd to hear about an application which can load a server by sending fewer than 1 request every 10 seconds, however, if one is using sticky sessions, one is not balancing _requests_, one is balancing _logins_. The usage pattern for our enterprise application sees our users login relatively slowly, and once a user has their JSESSIONID, those http requests never see the mod_proxy_cluster balancing algorithm again. > It's nice that there is a config parameter now, which will allow us to balance properly again, but I would offer that since the behaviour of external users can completely break the algorithm this bug requires a more sophisticated fix. > If authoritative parties agree it's a good idea, I'm happy to write a patch that does the following: > 1) improves the documentation, more clearly explaining how the algorithm functions and alerting users to this parameter > 2) clean up a couple of straight-up documentation errors > 3) Modifies the internal_find_best_byrequest formula from: > {code:c} > status = lbstatus + (elected - oldelected) * 1000)/lbfactor; > {code} > to: > {code:c} > status = lbstatus + (elected - oldelected + 1) * 1000)/lbfactor > {code} > It seems to me that the current formula assumes that each node would be winning at least some elections during the LBstatusRecalTime window, so by adding 1 we can ensure that assumption is always true, and no worker ever gets a score of 0. > I did a bit of algebra and I'm pretty confident that this change won't influence the outcome of any elections. That could only happen if: > {noformat} > lfc - lfw > lfc*lsw - lfw*lsc > {noformat} > where lfc is the client load factor, lsc is the client's lbstatus, and simlar for lfw and lsw. > Since the election numbers are multiplied by 1000, and the max difference between two load factors is 99, I conclude it is impossible for the addition of a single election to both workers to change the outcome of the election. > So yeah, let me know. -- This message was sent by Atlassian Jira (v7.13.8#713008)

4 years, 1 month

1
0
0 / 0

[JBoss JIRA] (MODCLUSTER-712) drop support of httpd-2.2.x in branch 1.3.x

by Jean-Frederic Clere (Jira)

[ https://issues.redhat.com/browse/MODCLUSTER-712?page=com.atlassian.jira.p... ] Jean-Frederic Clere closed MODCLUSTER-712. ------------------------------------------ Resolution: Done fixed by https://github.com/modcluster/mod_proxy_cluster/commit/811f9390bae227e4f1... > drop support of httpd-2.2.x in branch 1.3.x > ------------------------------------------- > > Key: MODCLUSTER-712 > URL: https://issues.redhat.com/browse/MODCLUSTER-712 > Project: mod_cluster > Issue Type: Bug > Components: Native (httpd modules) > Affects Versions: 1.3.12.Final > Reporter: Jean-Frederic Clere > Assignee: Jean-Frederic Clere > Priority: Major > Fix For: 1.3.13.Final > > > Per httpd.apache.org 2.2.x is out of support since 2017... Time to clean -- This message was sent by Atlassian Jira (v7.13.8#713008)

4 years, 1 month

1
0
0 / 0

[JBoss JIRA] (MODCLUSTER-713) error when build with httpd configure with --enable-maintainer-mode

by Jean-Frederic Clere (Jira)

[ https://issues.redhat.com/browse/MODCLUSTER-713?page=com.atlassian.jira.p... ] Jean-Frederic Clere closed MODCLUSTER-713. ------------------------------------------ Resolution: Done Fixed by https://github.com/modcluster/mod_proxy_cluster/commit/811f9390bae227e4f1... > error when build with httpd configure with --enable-maintainer-mode > ------------------------------------------------------------------- > > Key: MODCLUSTER-713 > URL: https://issues.redhat.com/browse/MODCLUSTER-713 > Project: mod_cluster > Issue Type: Bug > Components: Native (httpd modules) > Reporter: Jean-Frederic Clere > Assignee: Jean-Frederic Clere > Priority: Major > > you will get errors like: > +++ > ../include/node.h:241:1: error: function declaration isn’t a prototype [-Werror=strict-prototypes] > 241 | void (*lock_nodes)(); > +++ > or: > +++ > mod_proxy_cluster.c:2965:6: error: no previous prototype for ‘remove_session_route’ [-Werror=missing-prototypes] > 2965 | void remove_session_route(request_rec *r, const char *name) > | ^~~~~~~~~~~~~~~~~~~~ > +++ > or: > mod_proxy_cluster.c:3360:17: error: ‘strncpy’ specified bound 80 equals destination size [-Werror=stringop-truncation] > 3360 | strncpy(ou.JVMRoute, route, JVMROUTESZ); > | ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ -- This message was sent by Atlassian Jira (v7.13.8#713008)

4 years, 1 month

1
0
0 / 0

[JBoss JIRA] (MODCLUSTER-675) Failover scenario is not performed with httpd balancer - balancer fails to respond

by Jean-Frederic Clere (Jira)

[ https://issues.redhat.com/browse/MODCLUSTER-675?page=com.atlassian.jira.p... ] Jean-Frederic Clere closed MODCLUSTER-675. ------------------------------------------ Resolution: Done Fixed by https://github.com/modcluster/mod_cluster/commit/673a2e2406be670fdcef7dec... > Failover scenario is not performed with httpd balancer - balancer fails to respond > ---------------------------------------------------------------------------------- > > Key: MODCLUSTER-675 > URL: https://issues.redhat.com/browse/MODCLUSTER-675 > Project: mod_cluster > Issue Type: Bug > Components: Native (httpd modules) > Affects Versions: 1.3.8.Final > Environment: RHEL 7, CentOS 7 on x86_64 platform > Reporter: Jan Kasik > Assignee: Jean-Frederic Clere > Priority: Blocker > Fix For: 1.3.12.Final > > Attachments: error_log, httpd.zip, wildfly-16.0.0.Beta1-SNAPSHOT.zip > > > When second request in failover scenario is made to check whether the failover was done, server fails to respond. With Undertow as a balancer, this behavior cannot be reproduced. When I replace the jvmroute part by worker which is still alive, I got expected response. > {noformat}# curl -v --cookie "JSESSIONID=54yxdncGr5im0fBLqIIUMon0klbS66X16aYC_cVW.jboss-eap-7.2-3" http://172.17.0.2:2080/clusterbench/jvmroute > * About to connect() to 172.17.0.2 port 2080 (#0) > * Trying 172.17.0.2... > * Connected to 172.17.0.2 (172.17.0.2) port 2080 (#0) > > GET /clusterbench/jvmroute HTTP/1.1 > > User-Agent: curl/7.29.0 > > Host: 172.17.0.2:2080 > > Accept: */* > > Cookie: JSESSIONID=54yxdncGr5im0fBLqIIUMon0klbS66X16aYC_cVW.jboss-eap-7.2-3 > > > * Empty reply from server > * Connection #0 to host 172.17.0.2 left intact > curl: (52) Empty reply from server > {noformat} -- This message was sent by Atlassian Jira (v7.13.8#713008)

4 years, 1 month

1
0
0 / 0

[JBoss JIRA] (MODCLUSTER-675) Failover scenario is not performed with httpd balancer - balancer fails to respond

by Jean-Frederic Clere (Jira)

[ https://issues.redhat.com/browse/MODCLUSTER-675?page=com.atlassian.jira.p... ] Jean-Frederic Clere updated MODCLUSTER-675: ------------------------------------------- Fix Version/s: 1.3.12.Final > Failover scenario is not performed with httpd balancer - balancer fails to respond > ---------------------------------------------------------------------------------- > > Key: MODCLUSTER-675 > URL: https://issues.redhat.com/browse/MODCLUSTER-675 > Project: mod_cluster > Issue Type: Bug > Components: Native (httpd modules) > Affects Versions: 1.3.8.Final > Environment: RHEL 7, CentOS 7 on x86_64 platform > Reporter: Jan Kasik > Assignee: Jean-Frederic Clere > Priority: Blocker > Fix For: 1.3.12.Final > > Attachments: error_log, httpd.zip, wildfly-16.0.0.Beta1-SNAPSHOT.zip > > > When second request in failover scenario is made to check whether the failover was done, server fails to respond. With Undertow as a balancer, this behavior cannot be reproduced. When I replace the jvmroute part by worker which is still alive, I got expected response. > {noformat}# curl -v --cookie "JSESSIONID=54yxdncGr5im0fBLqIIUMon0klbS66X16aYC_cVW.jboss-eap-7.2-3" http://172.17.0.2:2080/clusterbench/jvmroute > * About to connect() to 172.17.0.2 port 2080 (#0) > * Trying 172.17.0.2... > * Connected to 172.17.0.2 (172.17.0.2) port 2080 (#0) > > GET /clusterbench/jvmroute HTTP/1.1 > > User-Agent: curl/7.29.0 > > Host: 172.17.0.2:2080 > > Accept: */* > > Cookie: JSESSIONID=54yxdncGr5im0fBLqIIUMon0klbS66X16aYC_cVW.jboss-eap-7.2-3 > > > * Empty reply from server > * Connection #0 to host 172.17.0.2 left intact > curl: (52) Empty reply from server > {noformat} -- This message was sent by Atlassian Jira (v7.13.8#713008)

4 years, 1 month

1
0
0 / 0

[JBoss JIRA] (MODCLUSTER-699) shm logic wrongly operates MemManagerFile directory when -X is used

by Jean-Frederic Clere (Jira)

[ https://issues.redhat.com/browse/MODCLUSTER-699?page=com.atlassian.jira.p... ] Jean-Frederic Clere closed MODCLUSTER-699. ------------------------------------------ Resolution: Cannot Reproduce > shm logic wrongly operates MemManagerFile directory when -X is used > ------------------------------------------------------------------- > > Key: MODCLUSTER-699 > URL: https://issues.redhat.com/browse/MODCLUSTER-699 > Project: mod_cluster > Issue Type: Bug > Affects Versions: 2.0.0.Alpha1, 2.0.0.Alpha2 > Reporter: Michal Karm > Assignee: Jean-Frederic Clere > Priority: Blocker > Attachments: shm-canot-run-httpd-X.png > > > !shm-canot-run-httpd-X.png! > [mod_manager.c#L656|https://github.com/modcluster/mod_proxy_cluster/blob/m...] -- This message was sent by Atlassian Jira (v7.13.8#713008)

4 years, 1 month

1
0
0 / 0

[JBoss JIRA] (MODCLUSTER-438) WebSocket support for mod_cluster

by Jason Jijón (Jira)

[ https://issues.redhat.com/browse/MODCLUSTER-438?page=com.atlassian.jira.p... ] Jason Jijón commented on MODCLUSTER-438: ---------------------------------------- Thank you for this fix. Which versions of mod_cluster native and httpd should I use for this? > WebSocket support for mod_cluster > --------------------------------- > > Key: MODCLUSTER-438 > URL: https://issues.redhat.com/browse/MODCLUSTER-438 > Project: mod_cluster > Issue Type: Feature Request > Components: Native (httpd modules) > Affects Versions: 1.3.2.Final > Reporter: Michal Karm > Assignee: Jean-Frederic Clere > Priority: Critical > Fix For: 2.0.0.Alpha2, 1.3.13.Final > > > * take a look at mod_proxy_wstunnel > * mod_cluster should be able to load balance WebSocket connections to worker nodes > * consider high-availability with respect to WebSockets > Additional details TBD... -- This message was sent by Atlassian Jira (v7.13.8#713008)

4 years, 1 month

1
0
0 / 0

[JBoss JIRA] (MODCLUSTER-580) EnableWsTunnel enables only ws comunication

by Jason Jijón (Jira)

[ https://issues.redhat.com/browse/MODCLUSTER-580?page=com.atlassian.jira.p... ] Jason Jijón commented on MODCLUSTER-580: ---------------------------------------- Thank you very much for fixing this. Which version of mod_cluster native fixes this? > EnableWsTunnel enables only ws comunication > ------------------------------------------- > > Key: MODCLUSTER-580 > URL: https://issues.redhat.com/browse/MODCLUSTER-580 > Project: mod_cluster > Issue Type: Bug > Components: Native (httpd modules) > Affects Versions: 1.3.5.Final > Reporter: Bogdan Sikora > Assignee: Jean-Frederic Clere > Priority: Major > > WebSocket configuration for apache httpd (EnableWsTunnel) balancer enables only ws communication, but undertow as balancer enables both http and ws. > {noformat} > # mod_proxy_balancer should be disabled when mod_cluster is used > LoadModule proxy_cluster_module modules/mod_proxy_cluster.so > LoadModule cluster_slotmem_module modules/mod_cluster_slotmem.so > LoadModule manager_module modules/mod_manager.so > LoadModule advertise_module modules/mod_advertise.so > MemManagerFile /mnt/hudson_workspace/mod_cluster/jbcs-httpd24-2.4/httpd/cache/mod_cluster > ServerName dev89:2080 > EnableWsTunnel > LogLevel warn > <IfModule manager_module> > Listen 10.19.70.244:8747 > <VirtualHost 10.19.70.244:8747> > <Directory /> > Require all granted > </Directory> > ServerAdvertise on > EnableMCPMReceive > <Location /mcm> > SetHandler mod_cluster-manager > Require all granted > </Location> > AdvertiseGroup 224.0.5.244:55918 > AdvertiseBindAddress 10.19.70.244:55918 > KeepAliveTimeout 60 > MaxKeepAliveRequests 0 > ServerAdvertise on > AdvertiseFrequency 5 > ManagerBalancerName qacluster > </VirtualHost> > </IfModule> > {noformat} > Worker joins with > {noformat} > <h1> Node jboss-eap-7.1 (ws://10.19.70.244:8080): </h1> > {noformat} > and all http comunication ends with > {noformat} > <!DOCTYPE HTML PUBLIC "-//IETF//DTD HTML 2.0//EN"> > <html><head> > <title>500 Internal Server Error</title> > </head><body> > <h1>Internal Server Error</h1> > <p>The server encountered an internal error or > misconfiguration and was unable to complete > your request.</p> > <p>Please contact the server administrator at > Administrator@localhost to inform them of the time this error occurred, > and the actions you performed just before this error.</p> > <p>More information about this error may be available > in the server error log.</p> > <hr> > <address>Apache/2.4.23 (Red Hat) Server at 10.19.70.244 Port 2080</address> > </body></html> > {noformat} > And log message > {noformat} > [Sat Apr 08 16:21:29.335633 2017] [proxy:warn] [pid 12680] [client 10.19.70.244:55922] AH01144: No protocol handler was valid for the URL /clusterbench/jvmroute. If you are using a DSO version of mod_proxy, make sure the proxy submodules are included in the configuration using LoadModule. > {noformat} -- This message was sent by Atlassian Jira (v7.13.8#713008)

4 years, 1 month

1
0
0 / 0

[JBoss JIRA] (MODCLUSTER-438) WebSocket support for mod_cluster

by Jean-Frederic Clere (Jira)

[ https://issues.redhat.com/browse/MODCLUSTER-438?page=com.atlassian.jira.p... ] Jean-Frederic Clere resolved MODCLUSTER-438. -------------------------------------------- Fix Version/s: 1.3.13.Final Resolution: Done Several issue related to WebSocket have been fixed, like MODCLUSTER-580 EnableWsTunnel Allow to switch all http/https to ws/wss URL switching from mod_proxy_http to mod_proxy_wstunnel WSUpgradeHeader value Allow to have a global value to fill the upgrade from the https://httpd.apache.org/docs/2.4/mod/mod_proxy_wstunnel.html both of those are global: they apply to all VrtualHost > WebSocket support for mod_cluster > --------------------------------- > > Key: MODCLUSTER-438 > URL: https://issues.redhat.com/browse/MODCLUSTER-438 > Project: mod_cluster > Issue Type: Feature Request > Components: Native (httpd modules) > Affects Versions: 1.3.2.Final > Reporter: Michal Karm > Assignee: Jean-Frederic Clere > Priority: Critical > Fix For: 2.0.0.Alpha2, 1.3.13.Final > > > * take a look at mod_proxy_wstunnel > * mod_cluster should be able to load balance WebSocket connections to worker nodes > * consider high-availability with respect to WebSockets > Additional details TBD... -- This message was sent by Atlassian Jira (v7.13.8#713008)

4 years, 1 month

1
0
0 / 0

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

mod_cluster-issues March 2020