November 2010 - mod_cluster-issues

[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, 2 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, 3 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, 3 months

2
1
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, 3 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, 3 months

3
8
0 / 0

[JBoss JIRA] Created: (MODCLUSTER-195) mod_cluster-manager does not update when a node is taken down

by Samuel Mendenhall (JIRA)

mod_cluster-manager does not update when a node is taken down ------------------------------------------------------------- Key: MODCLUSTER-195 URL: https://jira.jboss.org/browse/MODCLUSTER-195 Project: mod_cluster Issue Type: Bug Affects Versions: 1.0.4.GA Environment: mod_cluster 1.0.4.GA EAP 5.0.1.GA Reporter: Samuel Mendenhall Assignee: Jean-Frederic Clere Priority: Minor Fix For: 1.0.5 The mod_cluster-manager status page does not get updated on failover, the node still shows up as active and available balancer: [1] Name: mycluster Sticky: 1 [JSESSIONID]/[jsessionid] remove: 0 force: 0 Timeout: 0 Maxtry: 1 node: [1:1],Balancer: mycluster,JVMRoute: node01,Domain: [],Host: 10.0.242.204,Port: 8009,Type: ajp,flushpackets: 0,flushwait: 10,ping: 10,smax: 1,ttl: 60,timeout: 0 node: [2:2],Balancer: mycluster,JVMRoute: node02,Domain: [],Host: 10.0.242.205,Port: 8009,Type: ajp,flushpackets: 0,flushwait: 10,ping: 10,smax: 1,ttl: 60,timeout: 0 host: 1 [localhost] vhost: 1 node: 1 host: 2 [localhost] vhost: 1 node: 2 context: 1 [/load-demo] vhost: 1 node: 1 status: 1 context: 2 [/thespike] vhost: 1 node: 1 status: 1 context: 3 [/load-demo] vhost: 1 node: 2 status: 1 context: 4 [/thespike] vhost: 1 node: 2 status: 1 This behaviour is already fixed in mod_cluster 1.1.x, just needs to be backported to 1.0.x and included in the EAP. -- This message is automatically generated by JIRA. - For more information on JIRA, see: http://www.atlassian.com/software/jira

13 years, 4 months

3
2
0 / 0

[JBoss JIRA] Created: (MODCLUSTER-196) Incorrect routing of requests when one context root is the prefix of another

by Ben Schofield (JIRA)

Incorrect routing of requests when one context root is the prefix of another ---------------------------------------------------------------------------- Key: MODCLUSTER-196 URL: https://jira.jboss.org/browse/MODCLUSTER-196 Project: mod_cluster Issue Type: Bug Affects Versions: 1.1.0.Final Environment: Apache 2.2.9 mod_cluster 1.1.0 JBoss EAP 5.0.1 Reporter: Ben Schofield Assignee: Jean-Frederic Clere JBoss instance A hosts application A which has a context root of /abc. JBoss instance B hosts application B which has a context root of /abc/xyz A and B are not in the same cluster. The behavior is the requests meant for application B are getting routed to application A on JBoss instance A and the result is an http error 404. A request to /abc/xyz/my.jsp should correctly go to application B on JBoss instance B. -- This message is automatically generated by JIRA. - For more information on JIRA, see: http://www.atlassian.com/software/jira

13 years, 4 months

3
4
0 / 0

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

mod_cluster-issues November 2010