January 2012 - mod_cluster-issues

[JBoss JIRA] (MODCLUSTER-254) AS7-1718 CLONE - mod_cluster needs consistent naming

by Jean-Frederic Clere (JIRA)

[ https://issues.jboss.org/browse/MODCLUSTER-254?page=com.atlassian.jira.pl... ] Jean-Frederic Clere updated MODCLUSTER-254: ------------------------------------------- Issue Type: Enhancement (was: Bug) Priority: Optional (was: Critical) > AS7-1718 CLONE - mod_cluster needs consistent naming > ---------------------------------------------------- > > Key: MODCLUSTER-254 > URL: https://issues.jboss.org/browse/MODCLUSTER-254 > Project: mod_cluster > Issue Type: Enhancement > Affects Versions: 1.1.3.Final > Reporter: Radoslav Husar > Assignee: Paul Ferraro > Priority: Optional > > Cloning over from AS7-1718 to reflect the community upstream request in mod_cluster. > --- > We have been running into issues with misspelt modcluster, mod_cluster and mod-cluster (and Mod-cluster) for quite some time now, making difficult time for users. Surely there are sometimes rules where we can't stick to proper naming but we should then be able to minimize to two names. > *project name = mod_cluster > *console name = "Mod_cluster Status" > *xsd schema filename = mod-cluster (./docs/schema/jboss-as-mod-cluster_1_0.xsd) > *xmlns = modcluster (eg xmlns="urn:jboss:domain:modcluster:1.0") > *xs elements = mod-cluster (eg mod-cluster-config) > *schema comments = mod_cluster (eg <!-- mod_cluster parameters ...) > *jar name = mod_cluster (ie mod_cluster-1.1.3.Final) > I am not going to name the EAP5 components where names are significantly changed too. > We need this madness to stop soon enough ;-( -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.jboss.org/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira

12 years, 4 months

1
0
0 / 0

[JBoss JIRA] Created: (MODCLUSTER-261) segmentation fault with nofailover=On and proxy in virtual host

by Tomas Huryn (JIRA)

segmentation fault with nofailover=On and proxy in virtual host --------------------------------------------------------------- Key: MODCLUSTER-261 URL: https://issues.jboss.org/browse/MODCLUSTER-261 Project: mod_cluster Issue Type: Bug Affects Versions: 1.1.3.Final Environment: RHEL 5.7, Apache HTTPD 2.2.3 (packaged) or Apache HTTPD 2.2.21 (compiled), EAP 5.1.1 Reporter: Tomas Huryn Assignee: Jean-Frederic Clere Priority: Blocker we have - two clusters (2 JBoss instances for cluster1 (inst1 and inst2), 1 JBoss instance for cluster2 (inst3)). All instances run on the same machine (as) with binding manager - AJP on JBoss (port 8009 (inst1), 8109 (inst2), 8209 (inst3)) - root context enabled, application is in ROOT.war - defined jvmRoute in server.xml (inst1 -Djboss.web.jvmRoute=as.jb1 , inst2 -Djboss.web.jvmRoute=as.jb2 , inst3 -Djboss.web.jvmRoute=as.cms1) - Apache HTTPD runs on separate machine (ws) we need - cluster1 has connection to inst1 and inst2 with sticky session (client with one session will be routed to one instance only) - cluster2 has connection to inst3 We had tryed 2 solutions with no success: SOLUTION 1 - all in virtual host <VirtualHost externalip:8080> ServerName web1 <Proxy balancer://cluster1/> Order deny,allow Allow from all BalancerMember ajp://as:8009/ route=as.jb1 BalancerMember ajp://as:8109/ route=as.jb2 </Proxy> ProxyPass / balancer://cluster1/ stickysession=JSESSIONID|jsessionid nofailover=On ProxyPassReverse / balancer://cluster1/ </VirtualHost> <VirtualHost externalip:8080> ServerName web2 <Proxy balancer://cluster2/> Order deny,allow Allow from all BalancerMember ajp://as:8209/ route=as.cms1 </Proxy> ProxyPass / balancer://cluster2/ stickysession=JSESSIONID|jsessionid nofailover=On ProxyPassReverse / balancer://cluster2/ </VirtualHost> Result: Solution generate segmentation fault in error log, where somebody try to browse web. If we remove nofailover=On, all works fine except stick session - requests are splited to inst1 and inst2. SOLUTION2 - apache wide configuration <Proxy balancer://cluster1/> Order deny,allow Allow from all BalancerMember ajp://as:8009/ route=as.jb1 BalancerMember ajp://as:8109/ route=as.jb2 </Proxy> <Proxy balancer://cluster2/> Order deny,allow Allow from all BalancerMember ajp://as:8209/ route=as.cms1 </Proxy> <VirtualHost externalip:8080> ServerName web1 ProxyPass / balancer://cluster1/ stickysession=JSESSIONID|jsessionid nofailover=On ProxyPassReverse / balancer://cluster1/ </VirtualHost> <VirtualHost externalip:8080> ServerName web2 ProxyPass / balancer://cluster2/ stickysession=JSESSIONID|jsessionid nofailover=On ProxyPassReverse / balancer://cluster2/ </VirtualHost> Result: Sticky session works fine (no segmentation fault), but requests for web1 is routed to inst3 (cluster2) too and requests for web2 is routed to inst1 (cluster1) too. So there is problem with existence of two proxy cluster conffiguration directive. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira

12 years, 4 months

2
1
0 / 0

[JBoss JIRA] Created: (MODCLUSTER-258) Error 503 using mod_cluster

by Jean-Frederic Clere (JIRA)

Error 503 using mod_cluster --------------------------- Key: MODCLUSTER-258 URL: https://issues.jboss.org/browse/MODCLUSTER-258 Project: mod_cluster Issue Type: Bug Affects Versions: 1.1.3.Final, MOD_CLUSTER_1_0_10_GA_CP02 Reporter: Jean-Frederic Clere Assignee: Jean-Frederic Clere Priority: Blocker Fix For: MOD_CLUSTER_1_0_10_GA_CP03, 1.1.4.Final -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira

12 years, 4 months

1
3
0 / 0

[JBoss JIRA] Created: (MODCLUSTER-252) routing table lookup creates performance issues.

by Jean-Frederic Clere (JIRA)

routing table lookup creates performance issues. ------------------------------------------------ Key: MODCLUSTER-252 URL: https://issues.jboss.org/browse/MODCLUSTER-252 Project: mod_cluster Issue Type: Bug Affects Versions: 1.1.3.Final, MOD_CLUSTER_1_0_10_GA_CP02 Environment: use ~ 200 workers Reporter: Jean-Frederic Clere Assignee: Jean-Frederic Clere Fix For: MOD_CLUSTER_1_0_10_GA_CP03, 1.1.4.Final the throughput goes down to ~ 5 req/s -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira

12 years, 4 months

4
8
0 / 0

[JBoss JIRA] Created: (MODCLUSTER-246) :read-attribute and :write-attribute Error in AS7

by Stefan Negrea (JIRA)

:read-attribute and :write-attribute Error in AS7 ------------------------------------------------- Key: MODCLUSTER-246 URL: https://issues.jboss.org/browse/MODCLUSTER-246 Project: mod_cluster Issue Type: Bug Affects Versions: 1.1.3.Final Reporter: Stefan Negrea Assignee: Jean-Frederic Clere :read-attribute(name=xyz) and :write-attribute(name=xyz,value=zyx) do not work in console with JBoss AS7.1 nightly builds. The expectation is that :read-attribute will return the current value of the property or the default value if the property has not been set. For :write-attribute the expectation is that all the properties listed in :read-resource-description can be set. The JBoss was started with the following command: bin/standalone.sh --server-config=standalone-ha.xml Here is the current output for invoking the two operations use the advertise attribute as an example. The outcome of both operations is failed. [standalone@localhost:9999 subsystem=modcluster] :read-attribute(name=advertise) { "outcome" => "failed", "failure-description" => "No known attribute advertise", "rolled-back" => true } [standalone@localhost:9999 subsystem=modcluster] :write-attribute(name=advertise,value=true) { "outcome" => "failed", "failure-description" => "No known attribute called advertise", "rolled-back" => true } -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira

12 years, 4 months

2
3
0 / 0

[JBoss JIRA] Created: (MODCLUSTER-236) Allow context lengths greater than 40

by Samuel Mendenhall (JIRA)

Allow context lengths greater than 40 ------------------------------------- Key: MODCLUSTER-236 URL: https://issues.jboss.org/browse/MODCLUSTER-236 Project: mod_cluster Issue Type: Feature Request Affects Versions: 1.1.2.Final Reporter: Samuel Mendenhall Assignee: Jean-Frederic Clere Fix For: 1.1.3.Final The mod_cluster 1.1 documentation states the following in the Limitation section: "Max context length 40 (for example myapp.war deploys in /myapp /myapp is the context)." This value should be at least doubled to 80 for use with ESB which creates long context names. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira

12 years, 4 months

2
3
0 / 0

[JBoss JIRA] Created: (MODCLUSTER-245) Calculate the MAXMESSSIZE dynamically

by Samuel Mendenhall (JIRA)

Calculate the MAXMESSSIZE dynamically ------------------------------------- Key: MODCLUSTER-245 URL: https://issues.jboss.org/browse/MODCLUSTER-245 Project: mod_cluster Issue Type: Feature Request Affects Versions: 1.1.2.Final Reporter: Samuel Mendenhall Assignee: Jean-Frederic Clere Fix For: 1.1.3.Final Calculate the MAXMESSIZE dynamically at start time from the rest of the configuration. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira

12 years, 4 months

3
6
0 / 0

[JBoss JIRA] Created: (MODCLUSTER-244) Increase the MAXMESSSIZE and allow it to be configurable

by Samuel Mendenhall (JIRA)

Increase the MAXMESSSIZE and allow it to be configurable -------------------------------------------------------- Key: MODCLUSTER-244 URL: https://issues.jboss.org/browse/MODCLUSTER-244 Project: mod_cluster Issue Type: Feature Request Affects Versions: 1.0.10 Reporter: Samuel Mendenhall Assignee: Jean-Frederic Clere Fix For: 1.0.11 The MCMP message size, MAXMESSSIZE, is a constant fixed to 1024 bytes. The MAXMESSSIZE should be increased and also configurable via a parameter. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira

12 years, 4 months

3
13
0 / 0

[JBoss JIRA] (MODCLUSTER-276) no training slash leads to 302

by Christoph Gostner (Created) (JIRA)

no training slash leads to 302 ------------------------------ Key: MODCLUSTER-276 URL: https://issues.jboss.org/browse/MODCLUSTER-276 Project: mod_cluster Issue Type: Bug Reporter: Christoph Gostner Assignee: Jean-Frederic Clere Setup and democlient are described in forum post. Apache httpd and AS7 are on the same VM with the name 'ci'. The internal mapping of the VM has a different name to make clear, that the JBoss instances aren't directly accessible. Calling 'http://ci:8000/demo7/' works as expected, but without the trailing slash (http://ci:8000/demo7) a 303 error happens. The browser gets a redirect to an internal URL http://cluster:8080/demo7/ which of course is not accessible. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.jboss.org/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira

12 years, 4 months

2
1
0 / 0

[JBoss JIRA] (MODCLUSTER-271) Error 404 after successful cluster switch

by Erhard Siegl (Created) (JIRA)

Error 404 after successful cluster switch ----------------------------------------- Key: MODCLUSTER-271 URL: https://issues.jboss.org/browse/MODCLUSTER-271 Project: mod_cluster Issue Type: Bug Affects Versions: 1.1.3.Final Reporter: Erhard Siegl Assignee: Jean-Frederic Clere mod_cluster with two JBoss 4 as backend. A client continuousely hits the server. When I shutdown the JBoss with the active session, the second takes over successfully. But then sometimes I get a 404 for a single hit. Parts from the logfile (with debug): [Thu Dec 29 19:16:07 2011] [debug] mod_proxy_ajp.c(644): proxy: AJP: serving URL ajp://192.168.40.129:8109/demo/ ... [Thu Dec 29 19:16:07 2011] [debug] ajp_header.c(516): ajp_unmarshal_response: status = 200 ... Shutdown of first node [Thu Dec 29 19:16:07 2011] [debug] mod_manager.c(2296): manager_handler DISABLE-APP (/) processing: "JVMRoute=cluster1&Alias=localhost&Context=%2Fdemo" [Thu Dec 29 19:16:07 2011] [debug] mod_manager.c(2339): manager_handler DISABLE-APP OK [Thu Dec 29 19:16:07 2011] [debug] mod_manager.c(1653): manager_trans STOP-APP (/) [Thu Dec 29 19:16:07 2011] [debug] mod_manager.c(2296): manager_handler STOP-APP (/) processing: "JVMRoute=cluster1&Alias=localhost&Context=%2Fdemo" [Thu Dec 29 19:16:07 2011] [debug] mod_manager.c(2339): manager_handler STOP-APP OK [Thu Dec 29 19:16:07 2011] [debug] mod_manager.c(1653): manager_trans REMOVE-APP (/) [Thu Dec 29 19:16:07 2011] [debug] mod_manager.c(2296): manager_handler REMOVE-APP (/) processing: "JVMRoute=cluster1&Alias=localhost&Context=%2Fdemo" [Thu Dec 29 19:16:07 2011] [debug] mod_manager.c(2339): manager_handler REMOVE-APP OK ... Successfully removed route [Thu Dec 29 19:16:08 2011] [debug] mod_proxy_ajp.c(644): proxy: AJP: serving URL ajp://192.168.123.231:8209/demo/ ... [Thu Dec 29 19:16:08 2011] [debug] ajp_header.c(516): ajp_unmarshal_response: status = 200 ... But then it uses ajp://192.168.40.129:8109/demo/ again and fails with 404 [Thu Dec 29 19:16:09 2011] [debug] proxy_util.c(1937): proxy: BALANCER: retrying the worker for (192.168.40.129) [Thu Dec 29 19:16:09 2011] [debug] proxy_util.c(1943): proxy: BALANCER: worker for (192.168.40.129) has been marked for retry [Thu Dec 29 19:16:09 2011] [debug] mod_proxy.c(993): Running scheme balancer handler (attempt 0) [Thu Dec 29 19:16:09 2011] [debug] mod_proxy_http.c(1930): proxy: HTTP: declining URL ajp://192.168.40.129:8109/demo/ [Thu Dec 29 19:16:09 2011] [debug] mod_proxy_scgi.c(508): [client 127.0.0.1] proxy: SCGI: declining URL ajp://192.168.40.129:8109/demo/ [Thu Dec 29 19:16:09 2011] [debug] mod_proxy_ajp.c(644): proxy: AJP: serving URL ajp://192.168.40.129:8109/demo/ [Thu Dec 29 19:16:09 2011] [debug] proxy_util.c(1999): proxy: AJP: has acquired connection for (192.168.40.129) [Thu Dec 29 19:16:09 2011] [debug] proxy_util.c(2055): proxy: connecting ajp://192.168.40.129:8109/demo/ to 192.168.40.129:8109 [Thu Dec 29 19:16:09 2011] [debug] proxy_util.c(2153): proxy: connected /demo/ to 192.168.40.129:8109 [Thu Dec 29 19:16:09 2011] [debug] ajp_utils.c(31): Into ajp_handle_cping_cpong [Thu Dec 29 19:16:09 2011] [debug] ajp_utils.c(102): ajp_handle_cping_cpong: Done [Thu Dec 29 19:16:09 2011] [debug] ajp_header.c(224): Into ajp_marshal_into_msgb [Thu Dec 29 19:16:09 2011] [debug] ajp_header.c(290): ajp_marshal_into_msgb: Header[0] [Accept-Encoding] = [identity] [Thu Dec 29 19:16:09 2011] [debug] ajp_header.c(290): ajp_marshal_into_msgb: Header[1] [Host] = [devjava] [Thu Dec 29 19:16:09 2011] [debug] ajp_header.c(290): ajp_marshal_into_msgb: Header[2] [Cookie] = [JSESSIONID=D6AcPj+99EObFqH+F9wjew**.cluster1] [Thu Dec 29 19:16:09 2011] [debug] ajp_header.c(290): ajp_marshal_into_msgb: Header[3] [Connection] = [close] [Thu Dec 29 19:16:09 2011] [debug] ajp_header.c(290): ajp_marshal_into_msgb: Header[4] [User-agent] = [Mozilla/4.0 (compatible; MSIE 5.5; Windows NT)] [Thu Dec 29 19:16:09 2011] [debug] ajp_header.c(450): ajp_marshal_into_msgb: Done [Thu Dec 29 19:16:09 2011] [debug] mod_proxy_ajp.c(265): proxy: APR_BUCKET_IS_EOS [Thu Dec 29 19:16:09 2011] [debug] mod_proxy_ajp.c(270): proxy: data to read (max 8186 at 4) [Thu Dec 29 19:16:09 2011] [debug] mod_proxy_ajp.c(285): proxy: got 0 bytes of data [Thu Dec 29 19:16:09 2011] [debug] ajp_header.c(687): ajp_read_header: ajp_ilink_received 04 [Thu Dec 29 19:16:09 2011] [debug] ajp_header.c(697): ajp_parse_type: got 04 [Thu Dec 29 19:16:09 2011] [debug] ajp_header.c(516): ajp_unmarshal_response: status = 404 -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.jboss.org/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira

12 years, 5 months

2
1
0 / 0

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

mod_cluster-issues January 2012