May 2010 - mod_cluster-issues - Jboss List Archives

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

2
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, 4 months

1
4
0 / 0

[JBoss JIRA] Created: (MODCLUSTER-115) mod_cluster Manual Technical Review

by Gary Meintjes (JIRA)

mod_cluster Manual Technical Review ----------------------------------- Key: MODCLUSTER-115 URL: https://jira.jboss.org/jira/browse/MODCLUSTER-115 Project: mod_cluster Issue Type: Task Environment: JBoss AS Reporter: Gary Meintjes Assignee: Patrick Macdonald Patrick, Please assign someone perform a technical review on this mod_cluster publication as discussed. The link to the publication is: http://documentation-stage.bne.redhat.com/docs/en-US/JBoss_Enterprise_App... Many thanx, Gary Meintjes -- 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, 8 months

3
2
0 / 0

[JBoss JIRA] Created: (MODCLUSTER-141) Use versioned docs

by Paul Ferraro (JIRA)

Use versioned docs ------------------ Key: MODCLUSTER-141 URL: https://jira.jboss.org/jira/browse/MODCLUSTER-141 Project: mod_cluster Issue Type: Task Affects Versions: 1.1.0.CR1 Reporter: Paul Ferraro Assignee: Jean-Frederic Clere Priority: Minor Trying to maintain one copy of the documentation for multiple versions simultaneously is proving to be a pain in the @ss... Magnolia is very cumbersome as a documentation tool because of its treatment of "paragraphs", especially with respect to code fragments (of which our docs have many). I recommend we keep all of the documentation in subversion (using doxia, docbook or similar) so that it is versioned along with the source code. The download page would contain links to the docs along side binary and source distributions. This seems to be how most jboss.org projects are setup. -- 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
6
0 / 0

[JBoss JIRA] Created: (MODCLUSTER-153) ManagerBalancerName doesn't work

by Jean-Frederic Clere (JIRA)

ManagerBalancerName doesn't work -------------------------------- Key: MODCLUSTER-153 URL: https://jira.jboss.org/jira/browse/MODCLUSTER-153 Project: mod_cluster Issue Type: Bug Environment: any Reporter: Jean-Frederic Clere Assignee: Jean-Frederic Clere mycluster is used whatever value you put in ManagerBalancerName -- 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, 12 months

1
4
0 / 0

[JBoss JIRA] Created: (MODCLUSTER-154) Update docs to include basic iptables rules to allow mod_cluster multicast traffic

by Samuel Mendenhall (JIRA)

Update docs to include basic iptables rules to allow mod_cluster multicast traffic ---------------------------------------------------------------------------------- Key: MODCLUSTER-154 URL: https://jira.jboss.org/jira/browse/MODCLUSTER-154 Project: mod_cluster Issue Type: Task Affects Versions: 1.1.0.CR1, 1.0.3.GA Reporter: Samuel Mendenhall Assignee: Jean-Frederic Clere Priority: Minor Fix For: 1.0.4.GA, 1.1.0.CR3 By default RHEL/Fedora iptables rules blocks multicast traffic. At least on a single JBoss node with Apache and JBoss on the same machine the following iptables rule allows multicast traffic. If this rule isn't in place http://localhost/mod_cluster-manager will not show any nodes as multicast is blocked and Apache<->JBoss won't communicate /sbin/iptables -I INPUT 5 -p udp -d 224.0.1.0/24 -j ACCEPT /etc/init.d/iptables save It may also be helpful to note the iptables rules when running in a cluster also as seen here: http://www.redhat.com/docs/en-US/JBoss_Enterprise_Application_Platform/5.... -- 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, 12 months

2
1
0 / 0

[JBoss JIRA] Created: (MODCLUSTER-139) Allow override of default clean shutdown behavior

by Paul Ferraro (JIRA)

Allow override of default clean shutdown behavior ------------------------------------------------- Key: MODCLUSTER-139 URL: https://jira.jboss.org/jira/browse/MODCLUSTER-139 Project: mod_cluster Issue Type: Feature Request Affects Versions: 1.1.0.CR1 Reporter: Paul Ferraro Assignee: Paul Ferraro Priority: Minor Fix For: 1.1.0.CR2 By default, if a web-app is declared <distributable/>, we will only wait until there are no pending requests and all sessions are safely replicated. Only if a web-app is not <distributable/>, do we wait until there are no more active sessions, since there is no session replication. We need the ability to allow the user to override this default behavior, and use session draining even for <distributable/> apps, to avoid overloading remaining servers with failover requests. -- 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, 12 months

1
2
0 / 0

[JBoss JIRA] Created: (MODCLUSTER-152) Redeploy EAR with @WebService annotated beans cause 404

by GÃ¡bor Auth (JIRA)

Redeploy EAR with @WebService annotated beans cause 404 ------------------------------------------------------- Key: MODCLUSTER-152 URL: https://jira.jboss.org/jira/browse/MODCLUSTER-152 Project: mod_cluster Issue Type: Bug Affects Versions: 1.1.0.CR1, 1.0.3.GA Environment: Linux hostname 2.6.18-194.el5xen #1 SMP Tue Mar 16 22:01:26 EDT 2010 x86_64 x86_64 x86_64 GNU/Linux JBoss 5.1.0.GA ModCluster 1.3.0.GA Reporter: GÃ¡bor Auth Assignee: Jean-Frederic Clere Attachments: Common-test.zip I've tested a ModCluster 1.0.3.GA with the load-demo.war, and it works; I've started a JMeter testcase with 200 threads, then I've stopped and started the one of the two AS node; I've undeployed in the node1 the load-demo.war, then I've deployed again the load-demo.war: not found any errors, it works, except some CacheManager NPE while the SessionCache is synchronizing: 14:16:28,261 ERROR [load-demo] Caught exception rolling back transaction java.lang.NullPointerException at org.jboss.web.tomcat.service.session.JBossCacheManager.loadSession(JBossCacheManager.java:1857) at org.jboss.web.tomcat.service.session.JBossCacheManager.findSession(JBossCacheManager.java:489) ). I've created a simple "echo" EJB with these annotations: @MTOM @Local @WebService @Stateless(mappedName = "hu.javaforum.modcluster.webservice.test.service.Test") @LocalBinding(jndiBinding = "hu.javaforum.modcluster.webservice.test.service.Test") @WebContext(contextRoot = "/ModCluster-test", urlPattern = "/service") @SOAPBinding(style = SOAPBinding.Style.DOCUMENT, parameterStyle = SOAPBinding.ParameterStyle.WRAPPED) public class TestBean implements Test { @Override @TransactionAttribute(TransactionAttributeType.SUPPORTS) public String process(@WebParam(name = "request") String request) { return request; } } I've created a JAR, and I've deployed it to the cluster nodes, it works, I've started a JMeter and soapUI tests, it works. Then I've undeployed this JAR in the node1, it works, all test passes. Then I've deployed again (or redeploy) this JAR in the node1, and I've seen some HTTP/404 error in the reply: HTTP Status 404 - /ModCluster-test/service [...] The requested resource (/ModCluster-test/service) is not available. I've seen it in the httpd's access_log: x.x.x.x - - [07/May/2010:14:26:20 +0200] "POST /ModCluster-test/service HTTP/1.1" 404 1056 "-" "Jakarta Commons-HttpClient/3.1" And I've seen it in the access.log in the node1: x.x.x.x - - [07/May/2010:14:26:20 +0200] "POST /ModCluster-test/service HTTP/1.1" 404 1056 It is bug? :) -- 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, 12 months

3
9
0 / 0

[JBoss JIRA] Created: (MODCLUSTER-145) mod_proxy timeout setting is not set correctly from nodeTimeout (JBoss) or ProxyTimeout (httpd) configuration in mod_cluster

by Brett Cave (JIRA)

mod_proxy timeout setting is not set correctly from nodeTimeout (JBoss) or ProxyTimeout (httpd) configuration in mod_cluster ---------------------------------------------------------------------------------------------------------------------------- Key: MODCLUSTER-145 URL: https://jira.jboss.org/jira/browse/MODCLUSTER-145 Project: mod_cluster Issue Type: Bug Affects Versions: 1.1.0.CR1 Environment: CentOS5.4 Xen host JBossAS 5.1.0.GA running on jdk6 backend, on 2 hosts. mod_cluster configured in clustered mode. httpd-2.2.3-31.el5.centos.4 with manual mod_cluster configuration on frontend server host multicast disabled at a network layer jgroups configured with TCP transport and PING/gossip discovery Reporter: Brett Cave Assignee: Jean-Frederic Clere If 1 backend AS process is killed, the frontend proxy still connects clients to the dead node. The node is removed from mod_proxy after 5 minutes. All requests are directed to the dead node. mod-cluster manager status shows the node as status=NOTOK. client connections to this node result in 503 errors. After backend is removed from configuration after 5 minutes, requests to httpd still result in 503 errors as request is routed to the unavailable node. Even new sessions from different hosts try to get routed to the dead node, resulting in 503 errors. The note on www.jboss.org/mod_cluster/java/properties.html: When nodeTimeout is not defined, the ProxyTimeout directive Proxy is used. If ProxyTimeout is not defined the server timeout (Timeout) is used (default 300 seconds). nodeTimeout, ProxyTimeout or Timeout is set at the socket level. As per the configuration below, nodeTimeout is set in the Listener configuration. In addition to that, ProxyTimeout has been enabled and disabled on the httpd server. Timeout is configured with default of 120. -- 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, 12 months

2
4
0 / 0

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

by Wim Vandenhaute (JIRA)

Quotes in jsessionId causing sticky sessions to fail ---------------------------------------------------- Key: MODCLUSTER-146 URL: https://jira.jboss.org/jira/browse/MODCLUSTER-146 Project: mod_cluster Issue Type: Bug Environment: JBoss 6 M2, mod_cluster's httpd Reporter: Wim Vandenhaute Assignee: Jean-Frederic Clere 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. - 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, 12 months

4
6
0 / 0

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

mod_cluster-issues May 2010