May 2010 - mod_cluster-issues - Jboss List Archives

[JBoss JIRA] Created: (MODCLUSTER-138) Allow configuration of stopContextTimeout units

by Paul Ferraro (JIRA)

Allow configuration of stopContextTimeout units ----------------------------------------------- Key: MODCLUSTER-138 URL: https://jira.jboss.org/jira/browse/MODCLUSTER-138 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 Currently, the value specified in stopContextTimeout configuration property is specified in seconds. For completions sake, we should add a second property to define the units of this property, with default of TimeUnit.SECONDS. -- 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

14 years, 7 months

1
1
0 / 0

[JBoss JIRA] Resolved: (MODCLUSTER-20) Adding the lifecycle listener dynamically

by Paul Ferraro (JIRA)

[ https://jira.jboss.org/jira/browse/MODCLUSTER-20?page=com.atlassian.jira.... ] Paul Ferraro resolved MODCLUSTER-20. ------------------------------------ Fix Version/s: 1.1.0.CR2 Resolution: Done The CatalinaEventHandlerAdapter listener will be added automatically if the jbossweb server is started before mod_cluster. > Adding the lifecycle listener dynamically > ----------------------------------------- > > Key: MODCLUSTER-20 > URL: https://jira.jboss.org/jira/browse/MODCLUSTER-20 > Project: mod_cluster > Issue Type: Feature Request > Reporter: Jean-Frederic Clere > Assignee: Paul Ferraro > Fix For: 1.1.0.CR2 > > -- 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

14 years, 7 months

1
0
0 / 0

[JBoss JIRA] Created: (MODCLUSTER-142) Use UUID for auto-generated jvmRoute

by Paul Ferraro (JIRA)

Use UUID for auto-generated jvmRoute ------------------------------------ Key: MODCLUSTER-142 URL: https://jira.jboss.org/jira/browse/MODCLUSTER-142 Project: mod_cluster Issue Type: Feature Request Affects Versions: 1.1.0.CR1 Reporter: Paul Ferraro Assignee: Paul Ferraro Fix For: 1.1.0.CR2 Currently, auto-generated jvm-routes are of the form: bind-address:port:engine-name This exposes internal addresses/ports and is not appropriate for production systems. To fix that, we can use UUIDs. e.g. InetAddress connectorAddress; int connectorPort; String engineName; int addressBytes = connectorAddress.getAddress().length; int intBytes = Integer.SIZE / Byte.SIZE; int charBytes = Character.SIZE / Byte.SIZE; ByteBuffer buffer = ByteBuffer.allocate(addressBytes + intBytes + (engineName.length() * charBytes)); buffer.put(connectorAddress.getAddress()); buffer.putInt(connectorPort); buffer.asCharBuffer().put(engine); String jvmRoute = UUID.nameUUIDFromBytes(buffer.array()).toString(); I can think of 2 disadvantages: 1. UUID jvm-routes will be, on average, longer than the current default, i.e. 36 characters as opposed to ~28. Not a significant difference there. 2. For development, exposing the address and port via the jvm route might be useful. To satisfy this requirement, we can make the use of UUIDs configurable. -- 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

14 years, 8 months

3
4
0 / 0

[JBoss JIRA] Created: (MODCLUSTER-148) Automatic generation of jvmRoute leads to non-stickiness

by Bela Ban (JIRA)

Automatic generation of jvmRoute leads to non-stickiness -------------------------------------------------------- Key: MODCLUSTER-148 URL: https://jira.jboss.org/jira/browse/MODCLUSTER-148 Project: mod_cluster Issue Type: Bug Affects Versions: 1.1.0.CR1 Reporter: Bela Ban Assignee: Jean-Frederic Clere Fix For: 1.1.0.CR2 When I don't set a jvmRoute in server.xml, the generated jvmRoute BINDADDR:PORT:ENGINE is not correctly appended to a jsessionid, and therefore doesn't preserve stickiness. To reproduce: - Remove jvmRoute from server.xml - Start a few nodes - Deploy a webapp which adds stuff to a session - Access the webapp a few times ==> It is not guaranteed that we hit the same node every time, as there is no stickiness -- 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

14 years, 8 months

2
1
0 / 0

[JBoss JIRA] Created: (MODCLUSTER-147) Failover doesn't work

by Bela Ban (JIRA)

Failover doesn't work --------------------- Key: MODCLUSTER-147 URL: https://jira.jboss.org/jira/browse/MODCLUSTER-147 Project: mod_cluster Issue Type: Bug Affects Versions: 1.1.0.CR1 Reporter: Bela Ban Assignee: Jean-Frederic Clere Priority: Blocker A simple failover for a given webapp (with session state) doesn't work, web.war is attached, steps to reproduce are below. Environment: - JBoss SVN trunk (April 30), approximately AS 6 M3 - mod-cluster provide httpd How to reproduce: 1. Start node1 2. Access a webapp (node1) 3. Start node2 4. Kill node1 5. Access the webapp, error: 2010-04-29 09:35:22,118 ERROR [org.apache.catalina.core.ContainerBase.[jboss.web].[localhost].[/SessionDemo].[jsp]] (ajp-192.168.1.5-8009-5) Servlet.service() for servlet jsp threw exception: java.lang.ClassNotFoundException: org.apache.jsp.index_jsp at java.net.URLClassLoader$1.run(URLClassLoader.java:202) [:1.6.0_18] at java.security.AccessController.doPrivileged(Native Method) [:1.6.0_18] at java.net.URLClassLoader.findClass(URLClassLoader.java:190) [:1.6.0_18] at org.apache.jasper.servlet.JasperLoader.loadClass(JasperLoader.java:135) [:] at org.apache.jasper.servlet.JasperLoader.loadClass(JasperLoader.java:67) [:] at org.jboss.web.tomcat.service.TomcatInjectionContainer.newInstance(TomcatInjectionContainer.java:276) [:6.0.0-SNAPSHOT] at org.apache.jasper.servlet.JspServletWrapper.getServlet(JspServletWrapper.java:145) [:] at org.apache.jasper.servlet.JspServletWrapper.service(JspServletWrapper.java:324) [:] at org.apache.jasper.servlet.JspServlet.serviceJspFile(JspServlet.java:326) [:] at org.apache.jasper.servlet.JspServlet.service(JspServlet.java:253) [:] at javax.servlet.http.HttpServlet.service(HttpServlet.java:847) [:1.0.0.Beta2] at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:336) [:] at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:242) [:] at org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:293) [:] at org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:191) [:] at org.jboss.web.tomcat.security.SecurityAssociationValve.invoke(SecurityAssociationValve.java:183) [:6.0.0-SNAPSHOT] at org.jboss.web.tomcat.service.session.ClusteredSessionValve.handleRequest(ClusteredSessionValve.java:135) [:6.0.0-SNAPSHOT] at org.jboss.web.tomcat.service.session.ClusteredSessionValve.invoke(ClusteredSessionValve.java:94) [:6.0.0-SNAPSHOT] at org.jboss.web.tomcat.service.session.JvmRouteValve.invoke(JvmRouteValve.java:88) [:6.0.0-SNAPSHOT] at org.jboss.web.tomcat.service.session.LockingValve.invoke(LockingValve.java:62) [:6.0.0-SNAPSHOT] at org.jboss.modcluster.catalina.CatalinaContext$RequestListenerValve.event(CatalinaContext.java:285) [:1.1.0.CR1] at org.jboss.modcluster.catalina.CatalinaContext$RequestListenerValve.invoke(CatalinaContext.java:261) [:1.1.0.CR1] at org.jboss.web.tomcat.security.JaccContextValve.invoke(JaccContextValve.java:95) [:6.0.0-SNAPSHOT] at org.jboss.web.tomcat.security.SecurityContextEstablishmentValve.process(SecurityContextEstablishmentValve.java:126) [:6.0.0-SNAPSHOT] at org.jboss.web.tomcat.security.SecurityContextEstablishmentValve.invoke(SecurityContextEstablishmentValve.java:70) [:6.0.0-SNAPSHOT] at org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:127) [:] at org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:102) [:] at org.jboss.web.tomcat.service.jca.CachedConnectionValve.invoke(CachedConnectionValve.java:158) [:6.0.0-SNAPSHOT] at org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:109) [:] at org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:368) [:] at org.apache.coyote.ajp.AjpProcessor.process(AjpProcessor.java:504) [:] at org.apache.coyote.ajp.AjpProtocol$AjpConnectionHandler.process(AjpProtocol.java:436) [:] at org.apache.tomcat.util.net.JIoEndpoint$Worker.run(JIoEndpoint.java:951) [:] at java.lang.Thread.run(Thread.java:619) [:1.6.0_18] -- 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

14 years, 8 months

2
6
0 / 0

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

mod_cluster-issues May 2010