June 2010 - mod_cluster-issues - Jboss List Archives

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

4
6
0 / 0

[JBoss JIRA] Created: (MODCLUSTER-135) update zlib to 1.2.4

by Jean-Frederic Clere (JIRA)

update zlib to 1.2.4 --------------------- Key: MODCLUSTER-135 URL: https://jira.jboss.org/jira/browse/MODCLUSTER-135 Project: mod_cluster Issue Type: Feature Request Reporter: Jean-Frederic Clere Assignee: Jean-Frederic Clere -- 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, 10 months

1
5
0 / 0

[JBoss JIRA] Created: (MODCLUSTER-161) NoClassDefFoundError running demo app against AS6

by Paul Ferraro (JIRA)

NoClassDefFoundError running demo app against AS6 ------------------------------------------------- Key: MODCLUSTER-161 URL: https://jira.jboss.org/browse/MODCLUSTER-161 Project: mod_cluster Issue Type: Bug Affects Versions: 1.1.0.CR2 Reporter: Paul Ferraro Assignee: Jean-Frederic Clere Fix For: 1.1.0.CR3 RecordServlet uses an obsolete class (org.apache.catalina.ServerFactory) to obtain a reference to the JBoss Web's Server object. ServerFactory was removed in the upcoming JBoss Web 3.0 release (used in AS6). We'll need to use some other mechanism to obtain a reference to the Server. -- 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

1
2
0 / 0

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

mod_cluster-issues June 2010