December 2014 - mod_cluster-issues

[JBoss JIRA] (MODCLUSTER-446) Change in AdvertiseSecurityKey on httpd side is ignored by running workers

by Jean-Frederic Clere (JIRA)

[ https://issues.jboss.org/browse/MODCLUSTER-446?page=com.atlassian.jira.pl... ] Jean-Frederic Clere commented on MODCLUSTER-446: ------------------------------------------------ hm it is a missing feature in fact ;-) > Change in AdvertiseSecurityKey on httpd side is ignored by running workers > -------------------------------------------------------------------------- > > Key: MODCLUSTER-446 > URL: https://issues.jboss.org/browse/MODCLUSTER-446 > Project: mod_cluster > Issue Type: Bug > Affects Versions: 1.2.10.Final, 1.3.1.Beta1 > Reporter: Michal Babacek > Assignee: Jean-Frederic Clere > > While strengtening the test coverage and tying some loose ends, I encountered the following behaviour. It's always reproducible. Please, take a look at it and comment whether you consider it being a quite evil bug, or whether I'm just being full of ideas :-) > h3. Steps to reproduce > # Setup Apache HTTP Server *balancer* with {{AdvertiseSecurityKey karmYYY}} and start it. > # Setup *worker 1* with {{advertise-security-key="karmXXX"}} and start it. > # Setup *worker 2* with {{advertise-security-key="karmYYY"}} and start it. > # *worker 2* talks to *balancer*, that's cool. > # *worker 1* does not talk to *balancer*, that's cool. > # Stop *balancer*. Keep both workers running. > # Setup Apache HTTP Server *balancer* with {{AdvertiseSecurityKey karmXXX}} and start it. > # Now, I would expect that {{verifyDigest}} for *worker 2* ceases to match and that there will be only *worker 1* registered with the *balancer*. What actually happens is that _both_ *worker 1* and *worker 2* are registered with the *balancer* now. STATUS messages are being sent and processed, workers are in OK state. > I took a look at the differences between master and 1.2.10 branch, especially with regard to MODCLUSTER-338 and MODCLUSTER-337, but it bares no connection to this issue. 1.2.10.Final and 1.3.1.Beta1 exhibit the same kind of behaviour. > According to the log, the digest logic is sane, i.e. one gets: > {noformat} > [org.jboss.modcluster.advertise.impl.AdvertiseListenerImpl] (pool-1-thread-1) Advertise message digest verification failed for server 1a3825d7-e3df-4b5d-9838-52a3756284b0 > {noformat} > , but the worker keeps sending STATUS OK messages anyhow. > Would it make sense for the worker to "leave" the balancer if the digest is suddenly not matching? -- This message was sent by Atlassian JIRA (v6.3.11#6341)

10 years

1
0
0 / 0

[JBoss JIRA] (MODCLUSTER-446) Change in AdvertiseSecurityKey on httpd side is ignored by running workers

by Michal Babacek (JIRA)

[ https://issues.jboss.org/browse/MODCLUSTER-446?page=com.atlassian.jira.pl... ] Michal Babacek commented on MODCLUSTER-446: ------------------------------------------- Soo, it is a bug then, right? *Gone* should be processed by the listener? > Change in AdvertiseSecurityKey on httpd side is ignored by running workers > -------------------------------------------------------------------------- > > Key: MODCLUSTER-446 > URL: https://issues.jboss.org/browse/MODCLUSTER-446 > Project: mod_cluster > Issue Type: Bug > Affects Versions: 1.2.10.Final, 1.3.1.Beta1 > Reporter: Michal Babacek > Assignee: Jean-Frederic Clere > > While strengtening the test coverage and tying some loose ends, I encountered the following behaviour. It's always reproducible. Please, take a look at it and comment whether you consider it being a quite evil bug, or whether I'm just being full of ideas :-) > h3. Steps to reproduce > # Setup Apache HTTP Server *balancer* with {{AdvertiseSecurityKey karmYYY}} and start it. > # Setup *worker 1* with {{advertise-security-key="karmXXX"}} and start it. > # Setup *worker 2* with {{advertise-security-key="karmYYY"}} and start it. > # *worker 2* talks to *balancer*, that's cool. > # *worker 1* does not talk to *balancer*, that's cool. > # Stop *balancer*. Keep both workers running. > # Setup Apache HTTP Server *balancer* with {{AdvertiseSecurityKey karmXXX}} and start it. > # Now, I would expect that {{verifyDigest}} for *worker 2* ceases to match and that there will be only *worker 1* registered with the *balancer*. What actually happens is that _both_ *worker 1* and *worker 2* are registered with the *balancer* now. STATUS messages are being sent and processed, workers are in OK state. > I took a look at the differences between master and 1.2.10 branch, especially with regard to MODCLUSTER-338 and MODCLUSTER-337, but it bares no connection to this issue. 1.2.10.Final and 1.3.1.Beta1 exhibit the same kind of behaviour. > According to the log, the digest logic is sane, i.e. one gets: > {noformat} > [org.jboss.modcluster.advertise.impl.AdvertiseListenerImpl] (pool-1-thread-1) Advertise message digest verification failed for server 1a3825d7-e3df-4b5d-9838-52a3756284b0 > {noformat} > , but the worker keeps sending STATUS OK messages anyhow. > Would it make sense for the worker to "leave" the balancer if the digest is suddenly not matching? -- This message was sent by Atlassian JIRA (v6.3.11#6341)

10 years

1
0
0 / 0

[JBoss JIRA] (MODCLUSTER-446) Change in AdvertiseSecurityKey on httpd side is ignored by running workers

by Jean-Frederic Clere (JIRA)

[ https://issues.jboss.org/browse/MODCLUSTER-446?page=com.atlassian.jira.pl... ] Jean-Frederic Clere commented on MODCLUSTER-446: ------------------------------------------------ Actually 2 multicast message are sent to the nodes: HTTP/1.0 403 Forbidden when httpd is stopping and HTTP/1.0 410 Gone just before removing the module. But those message aren't processed by the listeners, so the first httpd is remembered and the new is added. > Change in AdvertiseSecurityKey on httpd side is ignored by running workers > -------------------------------------------------------------------------- > > Key: MODCLUSTER-446 > URL: https://issues.jboss.org/browse/MODCLUSTER-446 > Project: mod_cluster > Issue Type: Bug > Affects Versions: 1.2.10.Final, 1.3.1.Beta1 > Reporter: Michal Babacek > Assignee: Jean-Frederic Clere > > While strengtening the test coverage and tying some loose ends, I encountered the following behaviour. It's always reproducible. Please, take a look at it and comment whether you consider it being a quite evil bug, or whether I'm just being full of ideas :-) > h3. Steps to reproduce > # Setup Apache HTTP Server *balancer* with {{AdvertiseSecurityKey karmYYY}} and start it. > # Setup *worker 1* with {{advertise-security-key="karmXXX"}} and start it. > # Setup *worker 2* with {{advertise-security-key="karmYYY"}} and start it. > # *worker 2* talks to *balancer*, that's cool. > # *worker 1* does not talk to *balancer*, that's cool. > # Stop *balancer*. Keep both workers running. > # Setup Apache HTTP Server *balancer* with {{AdvertiseSecurityKey karmXXX}} and start it. > # Now, I would expect that {{verifyDigest}} for *worker 2* ceases to match and that there will be only *worker 1* registered with the *balancer*. What actually happens is that _both_ *worker 1* and *worker 2* are registered with the *balancer* now. STATUS messages are being sent and processed, workers are in OK state. > I took a look at the differences between master and 1.2.10 branch, especially with regard to MODCLUSTER-338 and MODCLUSTER-337, but it bares no connection to this issue. 1.2.10.Final and 1.3.1.Beta1 exhibit the same kind of behaviour. > According to the log, the digest logic is sane, i.e. one gets: > {noformat} > [org.jboss.modcluster.advertise.impl.AdvertiseListenerImpl] (pool-1-thread-1) Advertise message digest verification failed for server 1a3825d7-e3df-4b5d-9838-52a3756284b0 > {noformat} > , but the worker keeps sending STATUS OK messages anyhow. > Would it make sense for the worker to "leave" the balancer if the digest is suddenly not matching? -- This message was sent by Atlassian JIRA (v6.3.11#6341)

10 years

1
0
0 / 0

[JBoss JIRA] (MODCLUSTER-446) Change in AdvertiseSecurityKey on httpd side is ignored by running workers

by Michal Babacek (JIRA)

Michal Babacek created MODCLUSTER-446: ----------------------------------------- Summary: Change in AdvertiseSecurityKey on httpd side is ignored by running workers Key: MODCLUSTER-446 URL: https://issues.jboss.org/browse/MODCLUSTER-446 Project: mod_cluster Issue Type: Bug Affects Versions: 1.3.1.Beta1, 1.2.10.Final Reporter: Michal Babacek Assignee: Jean-Frederic Clere While strengtening the test coverage and tying some loose ends, I encountered the following behaviour. It's always reproducible. Please, take a look at it and comment whether you consider it being a quite evil bug, or whether I'm just being full of ideas :-) h3. Steps to reproduce # Setup Apache HTTP Server *balancer* with {{AdvertiseSecurityKey karmYYY}} and start it. # Setup *worker 1* with {{advertise-security-key="karmXXX"}} and start it. # Setup *worker 2* with {{advertise-security-key="karmYYY"}} and start it. # *worker 2* talks to *balancer*, that's cool. # *worker 1* does not talk to *balancer*, that's cool. # Stop *balancer*. Keep both workers running. # Setup Apache HTTP Server *balancer* with {{AdvertiseSecurityKey karmXXX}} and start it. # Now, I would expect that {{verifyDigest}} for *worker 2* ceases to match and that there will be only *worker 1* registered with the *balancer*. What actually happens is that _both_ *worker 1* and *worker 2* are registered with the *balancer* now. STATUS messages are being sent and processed, workers are in OK state. I took a look at the differences between master and 1.2.10 branch, especially with regard to MODCLUSTER-338 and MODCLUSTER-337, but it bares no connection to this issue. 1.2.10.Final and 1.3.1.Beta1 exhibit the same kind of behaviour. According to the log, the digest logic is sane, i.e. one gets: {noformat} [org.jboss.modcluster.advertise.impl.AdvertiseListenerImpl] (pool-1-thread-1) Advertise message digest verification failed for server 1a3825d7-e3df-4b5d-9838-52a3756284b0 {noformat} , but the worker keeps sending STATUS OK messages anyhow. Would it make sense for the worker to "leave" the balancer if the digest is suddenly not matching? -- This message was sent by Atlassian JIRA (v6.3.11#6341)

10 years

1
0
0 / 0

[JBoss JIRA] (MODCLUSTER-445) Documentation: update docs SetHandler mod_cluster-manager (as opposed to mod_cluster_manager)

by Xiaohui Wu (JIRA)

[ https://issues.jboss.org/browse/MODCLUSTER-445?page=com.atlassian.jira.pl... ] Xiaohui Wu commented on MODCLUSTER-445: --------------------------------------- I raised the bug: https://bugzilla.redhat.com/show_bug.cgi?id=1168792 I downloaded the software from: https://access.redhat.com/jbossnetwork/restricted/softwareDownload.html?s... it should be changed? If so, I will reopen the bugzilla. > Documentation: update docs SetHandler mod_cluster-manager (as opposed to mod_cluster_manager) > --------------------------------------------------------------------------------------------- > > Key: MODCLUSTER-445 > URL: https://issues.jboss.org/browse/MODCLUSTER-445 > Project: mod_cluster > Issue Type: Bug > Components: Documentation & Demos > Reporter: Xiaohui Wu > Assignee: Radoslav Husar > > In the upstream doc: > http://docs.jboss.org/mod_cluster/1.2.0/html/native.config.html > see the chapter > 3.5.14. SetHandler mod_cluster-manager > <Location /mod_cluster-manager> > SetHandler mod_cluster-manager > So I think we need to change the <Location /mod_cluster-manager> to <Location /mod_cluster_manager> to keep consistency? And do not know which one is the correct name ? And looks like the screenshot also shows the mod_cluster-manager. -- This message was sent by Atlassian JIRA (v6.3.11#6341)

10 years

1
0
0 / 0

[JBoss JIRA] (MODCLUSTER-445) Documentation: update docs SetHandler mod_cluster-manager (as opposed to mod_cluster_manager)

by Radoslav Husar (JIRA)

[ https://issues.jboss.org/browse/MODCLUSTER-445?page=com.atlassian.jira.pl... ] Radoslav Husar reassigned MODCLUSTER-445: ----------------------------------------- Summary: Documentation: update docs SetHandler mod_cluster-manager (as opposed to mod_cluster_manager) (was: [Doc]update docs SetHandler mod_cluster-manager) Assignee: Radoslav Husar (was: Jean-Frederic Clere) Component/s: Documentation & Demos We should really synchronize on one, and it should be mod_cluster-manager, i.e. the handler should correspond to URL to avoid confusion. > Documentation: update docs SetHandler mod_cluster-manager (as opposed to mod_cluster_manager) > --------------------------------------------------------------------------------------------- > > Key: MODCLUSTER-445 > URL: https://issues.jboss.org/browse/MODCLUSTER-445 > Project: mod_cluster > Issue Type: Bug > Components: Documentation & Demos > Reporter: Xiaohui Wu > Assignee: Radoslav Husar > > In the upstream doc: > http://docs.jboss.org/mod_cluster/1.2.0/html/native.config.html > see the chapter > 3.5.14. SetHandler mod_cluster-manager > <Location /mod_cluster-manager> > SetHandler mod_cluster-manager > So I think we need to change the <Location /mod_cluster-manager> to <Location /mod_cluster_manager> to keep consistency? And do not know which one is the correct name ? And looks like the screenshot also shows the mod_cluster-manager. -- This message was sent by Atlassian JIRA (v6.3.11#6341)

10 years

1
0
0 / 0

[JBoss JIRA] (MODCLUSTER-445) Documentation: update docs SetHandler mod_cluster-manager (as opposed to mod_cluster_manager)

by Radoslav Husar (JIRA)

[ https://issues.jboss.org/browse/MODCLUSTER-445?page=com.atlassian.jira.pl... ] Radoslav Husar commented on MODCLUSTER-445: ------------------------------------------- Sadly, same issue is in the RPMs default config for mod_cluster, this will need to be raised in RHBZ. {noformat} [rhusar@x220 ~]$ cat /etc/httpd/conf.d/mod_cluster.conf.rpmnew # # This is mod_cluster module configuration file. Please refer to # mod_cluster README for more information on how to enable mod_cluster. # # LoadModule slotmem_module modules/mod_slotmem.so # LoadModule proxy_cluster_module modules/mod_proxy_cluster.so # LoadModule advertise_module modules/mod_advertise.so # LoadModule manager_module modules/mod_manager.so # # MemManagerFile /var/cache/httpd # # <VirtualHost *:80> # # EnableMCPMReceive true # # <Location /> # Require all granted # </Location> # # <Location /mod_cluster_manager> # SetHandler mod_cluster-manager # Require host 127.0.0.1 # </Location> # # </VirtualHost> {noformat} > Documentation: update docs SetHandler mod_cluster-manager (as opposed to mod_cluster_manager) > --------------------------------------------------------------------------------------------- > > Key: MODCLUSTER-445 > URL: https://issues.jboss.org/browse/MODCLUSTER-445 > Project: mod_cluster > Issue Type: Bug > Components: Documentation & Demos > Reporter: Xiaohui Wu > Assignee: Radoslav Husar > > In the upstream doc: > http://docs.jboss.org/mod_cluster/1.2.0/html/native.config.html > see the chapter > 3.5.14. SetHandler mod_cluster-manager > <Location /mod_cluster-manager> > SetHandler mod_cluster-manager > So I think we need to change the <Location /mod_cluster-manager> to <Location /mod_cluster_manager> to keep consistency? And do not know which one is the correct name ? And looks like the screenshot also shows the mod_cluster-manager. -- This message was sent by Atlassian JIRA (v6.3.11#6341)

10 years

1
0
0 / 0

[JBoss JIRA] (MODCLUSTER-443) mod_cluster doesn't recognize ; as a proper context delimiter causing 404s on requests with URL jsessionids

by Radoslav Husar (JIRA)

[ https://issues.jboss.org/browse/MODCLUSTER-443?page=com.atlassian.jira.pl... ] Radoslav Husar updated MODCLUSTER-443: -------------------------------------- Comment: was deleted (was: 1.2.11.Final -> 1.2.10.Final) > mod_cluster doesn't recognize ; as a proper context delimiter causing 404s on requests with URL jsessionids > ----------------------------------------------------------------------------------------------------------- > > Key: MODCLUSTER-443 > URL: https://issues.jboss.org/browse/MODCLUSTER-443 > Project: mod_cluster > Issue Type: Bug > Components: Native (httpd modules) > Affects Versions: 1.2.9.Final, 1.3.1.Alpha2 > Reporter: Aaron Ogburn > Assignee: Jean-Frederic Clere > Fix For: 1.3.1.Beta1, 1.2.11.Final > > > This is similar to MODCLUSTER-328, but in regards to ; instead of ?. > mod_cluster does not recognize ; as a delimiter when checking the request context. Thus with no trailing slash on index page requests, it treats ;jsessionid as part of the request context and tries to check the balancer for a deployed context of /helloworld;jsessionid=..., which doesn't exist and 404s. Adding the trailing slash, mod_cluster can properly delimit this and then sees the context (so /helloworld/;jsessionid=... works just fine). -- This message was sent by Atlassian JIRA (v6.3.11#6341)

10 years

1
0
0 / 0

[JBoss JIRA] (MODCLUSTER-443) mod_cluster doesn't recognize ; as a proper context delimiter causing 404s on requests with URL jsessionids

by Michal Babacek (JIRA)

[ https://issues.jboss.org/browse/MODCLUSTER-443?page=com.atlassian.jira.pl... ] Michal Babacek commented on MODCLUSTER-443: ------------------------------------------- It's actually 1.2.11.Final, sorry about the previous comment. > mod_cluster doesn't recognize ; as a proper context delimiter causing 404s on requests with URL jsessionids > ----------------------------------------------------------------------------------------------------------- > > Key: MODCLUSTER-443 > URL: https://issues.jboss.org/browse/MODCLUSTER-443 > Project: mod_cluster > Issue Type: Bug > Components: Native (httpd modules) > Affects Versions: 1.2.9.Final, 1.3.1.Alpha2 > Reporter: Aaron Ogburn > Assignee: Jean-Frederic Clere > Fix For: 1.3.1.Beta1, 1.2.11.Final > > > This is similar to MODCLUSTER-328, but in regards to ; instead of ?. > mod_cluster does not recognize ; as a delimiter when checking the request context. Thus with no trailing slash on index page requests, it treats ;jsessionid as part of the request context and tries to check the balancer for a deployed context of /helloworld;jsessionid=..., which doesn't exist and 404s. Adding the trailing slash, mod_cluster can properly delimit this and then sees the context (so /helloworld/;jsessionid=... works just fine). -- This message was sent by Atlassian JIRA (v6.3.11#6341)

10 years

1
0
0 / 0

[JBoss JIRA] (MODCLUSTER-443) mod_cluster doesn't recognize ; as a proper context delimiter causing 404s on requests with URL jsessionids

by Michal Babacek (JIRA)

[ https://issues.jboss.org/browse/MODCLUSTER-443?page=com.atlassian.jira.pl... ] Michal Babacek updated MODCLUSTER-443: -------------------------------------- Fix Version/s: 1.2.11.Final (was: 1.2.10.Final) > mod_cluster doesn't recognize ; as a proper context delimiter causing 404s on requests with URL jsessionids > ----------------------------------------------------------------------------------------------------------- > > Key: MODCLUSTER-443 > URL: https://issues.jboss.org/browse/MODCLUSTER-443 > Project: mod_cluster > Issue Type: Bug > Components: Native (httpd modules) > Affects Versions: 1.2.9.Final, 1.3.1.Alpha2 > Reporter: Aaron Ogburn > Assignee: Jean-Frederic Clere > Fix For: 1.3.1.Beta1, 1.2.11.Final > > > This is similar to MODCLUSTER-328, but in regards to ; instead of ?. > mod_cluster does not recognize ; as a delimiter when checking the request context. Thus with no trailing slash on index page requests, it treats ;jsessionid as part of the request context and tries to check the balancer for a deployed context of /helloworld;jsessionid=..., which doesn't exist and 404s. Adding the trailing slash, mod_cluster can properly delimit this and then sees the context (so /helloworld/;jsessionid=... works just fine). -- This message was sent by Atlassian JIRA (v6.3.11#6341)

10 years

1
0
0 / 0

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

mod_cluster-issues December 2014