December 2010 - mod_cluster-issues

[JBoss JIRA] Created: (MODCLUSTER-122) Advertise does not work on name-based virtual hosts

by Radoslav Husar (JIRA)

Advertise does not work on name-based virtual hosts --------------------------------------------------- Key: MODCLUSTER-122 URL: https://jira.jboss.org/jira/browse/MODCLUSTER-122 Project: mod_cluster Issue Type: Bug Affects Versions: 1.0.2.GA Environment: RHEL 5.4 Reporter: Radoslav Husar Assignee: Jean-Frederic Clere If you use Apache httpd name-based virtual hosts on the server with multiple IPs (without explicit configuration parameter ServerAdvertise On http://hostname:port), advertise does not work and sends 0.0.0.0 IP address to the back-end. This is problem when you have back-end server on the physically another machine. Module should use ServerName from the VirtualHost configuration value in this case (or this case should be documented). Refer to official Apache 2.2 documentation for more information on Name-based Virtual Host Support http://httpd.apache.org/docs/2.2/vhosts/name-based.html Snip from mod_cluster docs: > ServerAdvertise On http://hostname:port: Tell the hostname and port to use. Only needed if the VirtualHost is not > defined correctly or when VirtualHost is not used. Sample configuration: <VirtualHost *:8888> ServerName perf10 ... </VirtualHost> -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira

13 years, 9 months

2
12
0 / 0

[JBoss JIRA] Created: (MODCLUSTER-124) Make mod_cluster manager tolerant to F5 page refresh when disabled context

by Radoslav Husar (JIRA)

Make mod_cluster manager tolerant to F5 page refresh when disabled context -------------------------------------------------------------------------- Key: MODCLUSTER-124 URL: https://jira.jboss.org/jira/browse/MODCLUSTER-124 Project: mod_cluster Issue Type: Feature Request Affects Versions: 1.0.2.GA Reporter: Radoslav Husar Assignee: Jean-Frederic Clere Priority: Minor I ran into this and found it rather unfriendly, when I wanted to refresh the mod_cluster manager (mcm) server returned Error 500. This happens when the last command was operating with a node which is no longer in the list. For example disabling a context: http://jawa11:7777/mod_cluster-manager?nonce=a6302da7-faa0-4338-8d35-9a25... You can easily run into this since there is no clear way - a link - to get to the page without any parameters (supposingly following the Autorefresh link which is not always desired to turn it off). Thanks for considering! -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira

13 years, 9 months

2
5
0 / 0

[JBoss JIRA] Created: (MODCLUSTER-198) Can only rewrite from the root in httpd if there is a root context deployed in JBoss

by Samuel Mendenhall (JIRA)

Can only rewrite from the root in httpd if there is a root context deployed in JBoss ------------------------------------------------------------------------------------ Key: MODCLUSTER-198 URL: https://jira.jboss.org/browse/MODCLUSTER-198 Project: mod_cluster Issue Type: Bug Affects Versions: 1.0.4.GA Reporter: Samuel Mendenhall Assignee: Jean-Frederic Clere Priority: Minor Fix For: 1.1.1.Final See: http://community.jboss.org/thread/159462 ==== I have a working mod_cluster 1.0.4 in front of EAP 5.1 (.com). I have been advised to use mod_rewrite and it works well. But i'm curious about the following scenario: mod_cluster set to expose ROOT. ROOT.war removed from JBoss. /sample deployed to jboss. mod_cluster INFO looks like: Node: [1],Name: redcloud:8009:jboss.web,Balancer: uat,Domain: ,Host: 192.168.235.128,Port: 8009,Type: ajp,Flushpackets: Off,Flushwait: 10000,Ping: 10000000,Smax: 1,Ttl: 60000000,Elected: 0,Read: 0,Transfered: 0,Connected: 0,Load: 88 Vhost: [1:1:1], Alias: localhost Context: [1:1:1], Context: /sample, Status: ENABLED When i do: RewriteRule ^/sample/(.*)$ balancer://uat/sample/$1 [P,L] and ask for my.url/sample/ it works perfectly. If i do: RewriteRule ^/(.*)$ balancer://uat/sample/$1 [P,L] and go to my.url/ i get a 503 from apache and see [Wed Dec 01 07:37:20 2010] [debug] mod_proxy_cluster.c(962): get_balancer_by_node balancer NOT found [Wed Dec 01 07:37:20 2010] [debug] mod_proxy_cluster.c(962): get_balancer_by_node balancer NOT found [Wed Dec 01 07:37:20 2010] [debug] mod_proxy_cluster.c(1137): proxy: byrequests balancer FAILED [Wed Dec 01 07:37:20 2010] [error] proxy: CLUSTER: (balancer://uat). All workers are in error state in the apache logs. If i put ROOT.war back in, mod_cluster-manager INFO shows: Node: [1],Name: redcloud:8009:jboss.web,Balancer: uat,Domain: ,Host: 192.168.235.128,Port: 8009,Type: ajp,Flushpackets: Off,Flushwait: 10000,Ping: 10000000,Smax: 1,Ttl: 60000000,Elected: 0,Read: 0,Transfered: 0,Connected: 0,Load: 92 Vhost: [1:1:1], Alias: localhost Context: [1:1:1], Context: /sample, Status: ENABLED Context: [1:1:2], Context: /, Status: ENABLED and my.url/ works (and serves the sameple app under root context). So, my question is has anyone seen this behavior with mod_cluster and mod_rewrite? I don't mind having a "dummy" app in to make ROOT visible but i don't necessarily want to have to. ==== -- This message is automatically generated by JIRA. - For more information on JIRA, see: http://www.atlassian.com/software/jira

13 years, 10 months

3
18
0 / 0

[JBoss JIRA] Created: (MODCLUSTER-188) mod_cluster failover does not work for a /webappcontext when the / root context exists

by Samuel Mendenhall (JIRA)

mod_cluster failover does not work for a /webappcontext when the / root context exists -------------------------------------------------------------------------------------- Key: MODCLUSTER-188 URL: https://jira.jboss.org/browse/MODCLUSTER-188 Project: mod_cluster Issue Type: Bug Affects Versions: 1.1.0.Beta1, 1.0.4.GA Reporter: Samuel Mendenhall Assignee: Jean-Frederic Clere Fix For: 1.0.5, 1.1.1.Final Let's say for example that /webapp and / is mapped in mod_cluster and there are two JBoss instances. If in one JBoss instance you undeploy the /webapp, you would expect mod_cluster to failover to the other JBoss instance. However, this is not the case, mod_cluster will instead select the lesser context, the root context / and service the request from /webapp on the / context. The logic only tests for ENABLE and DISABLE the STOP is not tested. The failover of a context will only work currently if / or any smaller path is not deployed -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira

13 years, 10 months

3
5
0 / 0

[JBoss JIRA] Created: (MODCLUSTER-133) STATUS should retry the worker even if there was an error before.

by Jean-Frederic Clere (JIRA)

STATUS should retry the worker even if there was an error before. ----------------------------------------------------------------- Key: MODCLUSTER-133 URL: https://jira.jboss.org/jira/browse/MODCLUSTER-133 Project: mod_cluster Issue Type: Bug Environment: any Reporter: Jean-Frederic Clere Assignee: Jean-Frederic Clere Fix For: 1.1.0.CR1 Once an error occurs a STATUS should retry but the moment we have: +++ [Thu Feb 25 16:49:24 2010] [debug] ajp_header.c(687): ajp_read_header: ajp_ilink_received 09 [Thu Feb 25 16:49:24 2010] [debug] ajp_header.c(697): ajp_parse_type: got 09 [Thu Feb 25 16:49:24 2010] [debug] mod_proxy_ajp.c(540): proxy: Processing of request failed backend: 1, output: 0 [Thu Feb 25 16:49:24 2010] [error] proxy: dialog to 192.168.100.150:8009 (192.168.100.150) failed [Thu Feb 25 16:49:24 2010] [debug] proxy_util.c(2017): proxy: AJP: has released connection for (192.168.100.150) [Thu Feb 25 16:49:24 2010] [debug] mod_proxy_cluster.c(1118): proxy: byrequests balancer FAILED [Thu Feb 25 16:49:24 2010] [error] proxy: CLUSTER: (balancer://mycluster). All workers are in error state [Thu Feb 25 16:49:26 2010] [debug] mod_manager.c(1416): manager_trans STATUS (/) [Thu Feb 25 16:49:26 2010] [debug] mod_manager.c(1929): manager_handler STATUS (/) processing: "JVMRoute=node3&Load=78" [Thu Feb 25 16:49:26 2010] [debug] proxy_util.c(1937): proxy: ajp: retrying the worker for (192.168.100.150) [Thu Feb 25 16:49:26 2010] [error] proxy: ajp: disabled connection for (192.168.100.150) [Thu Feb 25 16:49:26 2010] [debug] mod_proxy_cluster.c(1333): proxy_cluster_isup: pingpong failed [Thu Feb 25 16:49:26 2010] [debug] mod_manager.c(1970): manager_handler STATUS OK [Thu Feb 25 16:49:36 2010] [debug] mod_manager.c(1416): manager_trans STATUS (/) [Thu Feb 25 16:49:36 2010] [debug] mod_manager.c(1929): manager_handler STATUS (/) processing: "JVMRoute=node3&Load=77" [Thu Feb 25 16:49:36 2010] [debug] proxy_util.c(1937): proxy: ajp: retrying the worker for (192.168.100.150) [Thu Feb 25 16:49:36 2010] [error] proxy: ajp: disabled connection for (192.168.100.150) +++ -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira

13 years, 11 months

1
4
0 / 0

[JBoss JIRA] Created: (MODCLUSTER-193) mod_cluster 1.1.0 docs step 11.1.4.3 is wrong

by Samuel Mendenhall (JIRA)

mod_cluster 1.1.0 docs step 11.1.4.3 is wrong --------------------------------------------- Key: MODCLUSTER-193 URL: https://jira.jboss.org/browse/MODCLUSTER-193 Project: mod_cluster Issue Type: Bug Affects Versions: 1.1.0.Final Reporter: Samuel Mendenhall Assignee: Jean-Frederic Clere Fix For: 1.1.1.Final http://docs.jboss.org/mod_cluster/1.1.0/html/UsingSSL.html Section: 11.1.4.3. Create the client certificate Step 2 ================================== mkdir -p CERTS/Client cd CERTS/Client ================================== This is incorrect, it is the copy of step 1 instead of how to actually "Create a new request and sign it for the client certificate and key of the JBossWEB part." -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira

13 years, 11 months

2
1
0 / 0

[JBoss JIRA] Created: (MODCLUSTER-200) Default maxAttempts set to -1 instead of 1

by Radoslav Husar (JIRA)

Default maxAttempts set to -1 instead of 1 ------------------------------------------ Key: MODCLUSTER-200 URL: https://issues.jboss.org/browse/MODCLUSTER-200 Project: mod_cluster Issue Type: Bug Affects Versions: 1.0.5, 1.0.4.GA Reporter: Radoslav Husar Assignee: Jean-Frederic Clere Priority: Minor Fix For: 1.0.6 See JBPAPP-3724 - not fixed completely - only in HA MC Service, not in standard MC Service. The property in mod-cluster-jboss-beans.xml: <property name="maxAttempts">-1</property> The number of maximum attempts must be logically a natural number (it is impossible to attempt minus one times :-) The documentation claims the default value is 1. This is not in sync and can lead to confusion. -- This message is automatically generated by JIRA. - For more information on JIRA, see: http://www.atlassian.com/software/jira

13 years, 11 months

2
2
0 / 0

[JBoss JIRA] Created: (MODCLUSTER-173) Alias max length too low

by Gregory Lardiere (JIRA)

Alias max length too low ------------------------ Key: MODCLUSTER-173 URL: https://jira.jboss.org/browse/MODCLUSTER-173 Project: mod_cluster Issue Type: Bug Affects Versions: 1.0.3.GA Environment: Windows server 2008 Reporter: Gregory Lardiere Assignee: Jean-Frederic Clere We have virtual-hosts in server.xml with aliases of more than 40 characters. No problem on the jboss side, but on apache side, mod_cluster fails with the following message : "MEM: Can't read host alias". Changing HOSTALIASZ from 40 to 64 (mod_clustersize.h) resolves the problem (see patch #1). NB: I had to fix a few "NMAKEmakefile", otherwise it won't compile with Visual Studio 2010 (see patch #2) -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira

13 years, 12 months

4
11
0 / 0

[JBoss JIRA] Created: (MODCLUSTER-190) mod_cluster issues an ENABLE-APP too early in the webapp lifecycle

by Samuel Mendenhall (JIRA)

mod_cluster issues an ENABLE-APP too early in the webapp lifecycle ------------------------------------------------------------------ Key: MODCLUSTER-190 URL: https://jira.jboss.org/browse/MODCLUSTER-190 Project: mod_cluster Issue Type: Bug Affects Versions: 1.0.4.GA Reporter: Samuel Mendenhall Assignee: Jean-Frederic Clere Fix For: 1.0.5 mod_cluster uses START_EVENT instead of a AFTER_START_EVENT so it might ENABLE the application too early. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira

13 years, 12 months

3
8
0 / 0

[JBoss JIRA] Created: (MODCLUSTER-203) CLONE - Quotes in jsessionId causing sticky sessions to fail

by Jean-Frederic Clere (JIRA)

CLONE - Quotes in jsessionId causing sticky sessions to fail ------------------------------------------------------------ Key: MODCLUSTER-203 URL: https://issues.jboss.org/browse/MODCLUSTER-203 Project: mod_cluster Issue Type: Bug Environment: JBoss 6 M2, mod_cluster's httpd Reporter: Wim Vandenhaute Assignee: Jean-Frederic Clere Fix For: 1.1.0.CR3 I am having an issue trying to setup sticky sessions for following configuration: 1 httpd front end 2 backend jboss instances What I am noticing is when running in a cluster, the JSESSIONID contains quotes like: Set-Cookie: JSESSIONID="DE0F7EEA2A5E90497D729DB27DDB4B25.192.168.7.11:8009:jboss.web"; Version=1; Path=/f00 Whilst not in a cluster: Set-Cookie: JSESSIONID=355F9E370912DC10187A15E8B02260CD; Path=/foo Now when I am looking in the httpd logging I see: mod_proxy_cluster.c(1681): cluster: Found value "54F0CFC4961C9ED14A64335B40645392.192.168.7.11:8009:jboss.web" for stickysession JSESSIONID In my opinion the quotes around the jsessionid is causing mod_proxy_cluster to fail in finding the jboss node to which to "stick" to. I recompiled mod_proxy_cluster with "HAVE_CLUSTER_EX_DEBUG" set for more debugging info and this confirmed my suspicion: mod_proxy_cluster.c(1739): find_nodedomain: finding node for 192.168.7.11:8009:jboss.web": mycluster mod_proxy_cluster.c(1752): find_nodedomain: finding domain for 192.168.7.11:8009:jboss.web": mycluster Looking in the code this shows that it was unable to find the node, due to the ending quote in the route. As for my JBoss Setup: * Uncommented ModClusterListener in jbossweb.sar/META-INF/jboss-beans.xml * mod_cluster.sar/META-INF/mod_cluster-jboss-beans.xml - changed ModClusterService to HAModClusterService - changed ${jboss.mod_cluster.advertise.enabled:false} to true As for my httpd setup: LoadModule proxy_module /opt/jboss/httpd/lib/httpd/modules/mod_proxy.so LoadModule proxy_ajp_module /opt/jboss/httpd/lib/httpd/modules/mod_proxy_ajp.so LoadModule slotmem_module /opt/jboss/httpd/lib/httpd/modules/mod_slotmem.so LoadModule manager_module /opt/jboss/httpd/lib/httpd/modules/mod_manager.so LoadModule proxy_cluster_module /opt/jboss/httpd/lib/httpd/modules/mod_proxy_cluster.so LoadModule advertise_module /opt/jboss/httpd/lib/httpd/modules/mod_advertise.so LogLevel debug CreateBalancers 0 <VirtualHost *:80> <Location /mod_cluster-manager> SetHandler mod_cluster-manager Order deny,allow Deny from all Allow from all # Allow from 192.168.7. </Location> <Directory /> Order deny,allow Deny from all Allow from all </Directory> ProxyPass /foo balancer://mycluster/foo stickysession=JSESSIONID scolonpathdelim=On nofailover=On KeepAliveTimeout 60 MaxKeepAliveRequests 0 ManagerBalancerName mycluster AdvertiseFrequency 5 </VirtualHost> Listen sebeco-dev-11:443 <VirtualHost *:443> ServerName sebeco-dev-11:443 SSLEngine on SSLProxyEngine on SSLCipherSuite ALL:!ADH:!EXPORT56:RC4+RSA:+HIGH:+MEDIUM:+LOW:+SSLv2:+EXP:+eNULL SSLCertificateFile "/opt/jboss/httpd/httpd/server.crt" SSLCertificateKeyFile "/opt/jboss/httpd/httpd/server.key" SSLCertificateChainFile "/opt/jboss/httpd/httpd/server-ca.crt" <FilesMatch "\.(cgi|shtml|phtml|php)$"> SSLOptions +StdEnvVars </FilesMatch> <Location /> Order allow,deny Allow from all </Location> ProxyPass /foo balancer://mycluster/foo stickysession=JSESSIONID scolonpathdelim=On nofailover=On </VirtualHost> As my setup is not really complex at this point my gut says I am doing something wrong in the setup, but digging in the code shows the opposite. Any thougts? Best regards, Wim. -- This message is automatically generated by JIRA. - For more information on JIRA, see: http://www.atlassian.com/software/jira

13 years, 12 months

1
2
0 / 0

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

mod_cluster-issues December 2010