August 2010 - mod_cluster-issues - Jboss List Archives

[JBoss JIRA] Created: (MODCLUSTER-160) Include link to mod_cluster config generator in publication mod_cluster User Guide.

by Gary Meintjes (JIRA)

Include link to mod_cluster config generator in publication mod_cluster User Guide. ----------------------------------------------------------------------------------- Key: MODCLUSTER-160 URL: https://jira.jboss.org/browse/MODCLUSTER-160 Project: mod_cluster Issue Type: Task Reporter: Gary Meintjes Assignee: Gary Meintjes Priority: Minor Insert a link in the publication to the mod_cluster configuration generating tool: http://lbconfig.appspot.com. Envisaged: Update trunk document for inclusion in EAP 5.1 release in August 2010. -- 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

12 years

3
4
0 / 0

[JBoss JIRA] Created: (MODCLUSTER-120) Apache with mod_cluster refuses to start at first, after 7 retries it starts up

by Radoslav Husar (JIRA)

Apache with mod_cluster refuses to start at first, after 7 retries it starts up ------------------------------------------------------------------------------- Key: MODCLUSTER-120 URL: https://jira.jboss.org/jira/browse/MODCLUSTER-120 Project: mod_cluster Issue Type: Bug Affects Versions: 1.0.2.GA Environment: x64, RHEL 5, Server version: Apache/2.2.3, Server built: Jul 6 2009 05:29:28 Reporter: Radoslav Husar Assignee: Jean-Frederic Clere When starting up Apache with mod cluster, by command: [hudson@perf10 httpd]$ /usr/sbin/apachectl -k start -d /tmp/hudson/httpd It refuses to start, but creates files in logs one-by-one and then when all files are created it accepts to start. [hudson@perf10 httpd]$ cat logs/error_log [Tue Jan 05 12:01:11 2010] [notice] suEXEC mechanism enabled (wrapper: /usr/sbin/suexec) [Tue Jan 05 12:01:11 2010] [notice] Digest: generating secret for digest authentication ... [Tue Jan 05 12:01:11 2010] [notice] Digest: done [Tue Jan 05 12:01:11 2010] [emerg] create_mem_node /tmp/hudson/httpd/logs/manager.node failed Configuration Failed [Tue Jan 05 12:01:37 2010] [notice] suEXEC mechanism enabled (wrapper: /usr/sbin/suexec) [Tue Jan 05 12:01:37 2010] [notice] Digest: generating secret for digest authentication ... [Tue Jan 05 12:01:37 2010] [notice] Digest: done [Tue Jan 05 12:01:37 2010] [emerg] create_mem_context failed Configuration Failed [Tue Jan 05 12:02:40 2010] [notice] suEXEC mechanism enabled (wrapper: /usr/sbin/suexec) [Tue Jan 05 12:02:40 2010] [notice] Digest: generating secret for digest authentication ... [Tue Jan 05 12:02:40 2010] [notice] Digest: done [Tue Jan 05 12:02:40 2010] [emerg] create_mem_host failed Configuration Failed [Tue Jan 05 12:04:43 2010] [notice] suEXEC mechanism enabled (wrapper: /usr/sbin/suexec) [Tue Jan 05 12:04:43 2010] [notice] Digest: generating secret for digest authentication ... [Tue Jan 05 12:04:43 2010] [notice] Digest: done [Tue Jan 05 12:04:43 2010] [emerg] create_mem_balancer failed Configuration Failed [Tue Jan 05 12:04:44 2010] [notice] suEXEC mechanism enabled (wrapper: /usr/sbin/suexec) [Tue Jan 05 12:04:44 2010] [notice] Digest: generating secret for digest authentication ... [Tue Jan 05 12:04:44 2010] [notice] Digest: done [Tue Jan 05 12:04:44 2010] [emerg] create_mem_sessionid failed Configuration Failed [Tue Jan 05 12:04:45 2010] [notice] suEXEC mechanism enabled (wrapper: /usr/sbin/suexec) [Tue Jan 05 12:04:45 2010] [notice] Digest: generating secret for digest authentication ... [Tue Jan 05 12:04:45 2010] [notice] Digest: done [Tue Jan 05 12:04:45 2010] [emerg] create_mem_domain failed Configuration Failed [Tue Jan 05 12:04:46 2010] [notice] suEXEC mechanism enabled (wrapper: /usr/sbin/suexec) [Tue Jan 05 12:04:46 2010] [notice] Digest: generating secret for digest authentication ... [Tue Jan 05 12:04:46 2010] [notice] Digest: done [Tue Jan 05 12:04:46 2010] [notice] Advertise initialized for process 1713 [Tue Jan 05 12:04:46 2010] [notice] Apache/2.2.3 (Red Hat) configured -- resuming normal operations The configuration is here: https://svn.devel.redhat.com/repos/jboss-qa/load-testing/etc/httpd/mod_cl... Is there a workaround? What might be causing this? -- 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

12 years, 1 month

4
32
0 / 0

[JBoss JIRA] Created: (MODCLUSTER-168) mod_cluster should use hostname provided in address instead a IP address

by Jean-Frederic Clere (JIRA)

mod_cluster should use hostname provided in address instead a IP address ------------------------------------------------------------------------ Key: MODCLUSTER-168 URL: https://jira.jboss.org/browse/MODCLUSTER-168 Project: mod_cluster Issue Type: Feature Request Affects Versions: 1.1.0.CR3 Environment: any Reporter: Jean-Frederic Clere Assignee: Jean-Frederic Clere The CONFIG message contains something like: JVMRoute=51ec121e-2976-3d75-bfd9-9e662bbb4bcd&Host=10.33.144.3&Port=8009&Type=ajp Even if the Connector is defined like: <Connector port="8009" address= "jfcpc" protocol="AJP/1.3" redirectPort="8443" /> There are 2 ways to fix: - Use the String (Change the Connector.java in mod_cluster). - Use parameters.put("Host", connector.getAddress().getHostName()); when building the CONFIG message. -- 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

12 years, 2 months

3
17
0 / 0

[JBoss JIRA] Created: (MODCLUSTER-140) Rpc failure can lead to failure to deploy a webapp

by Paul Ferraro (JIRA)

Rpc failure can lead to failure to deploy a webapp -------------------------------------------------- Key: MODCLUSTER-140 URL: https://jira.jboss.org/jira/browse/MODCLUSTER-140 Project: mod_cluster Issue Type: Bug Affects Versions: 1.1.0.CR1, 1.0.3.GA Reporter: Paul Ferraro Assignee: Paul Ferraro Fix For: 1.0.4.GA, 1.1.0.CR2 An exception thrown during an rpc call should never propagate to the web container. See stack trace in forum thread. -- 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

12 years, 4 months

2
3
0 / 0

[JBoss JIRA] Created: (MODCLUSTER-91) Connector bind address of 0.0.0.0 propagated to proxy

by Brian Stansberry (JIRA)

Connector bind address of 0.0.0.0 propagated to proxy ----------------------------------------------------- Key: MODCLUSTER-91 URL: https://jira.jboss.org/jira/browse/MODCLUSTER-91 Project: mod_cluster Issue Type: Bug Affects Versions: 1.0.1.GA Reporter: Brian Stansberry Assignee: Jean-Frederic Clere Marek Goldmann wrote: > I'm encountered a strange error. When I bind JBoss instance to 0.0.0.0 > address instead of a fixed ethernet address, node gets registered in > mod_cluster, shows in mod_cluster-manager, but every request to > registered contexts throws 503 error. > > httpd error log: > > [Fri Aug 07 03:21:05 2009] [error] (111)Connection refused: proxy: > ajp: attempt to connect to 0.0.0.0:8009 (0.0.0.0) failed > [Fri Aug 07 03:21:05 2009] [error] ap_proxy_connect_backend disabling > worker for (0.0.0.0) > [Fri Aug 07 03:21:15 2009] [error] proxy: ajp: disabled connection for > (0.0.0.0) > [Fri Aug 07 03:21:25 2009] [error] proxy: ajp: disabled connection for > (0.0.0.0) > > This looks like a bug for me, because many administrators are binding > JBoss to 0.0.0.0. The java side needs to understand that 0.0.0.0 is useless as a client address and send something useful. Trick is deciding what's useful. -- 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

12 years, 5 months

4
12
0 / 0

[JBoss JIRA] Created: (MODCLUSTER-151) Modify jbossweb metrics to use service provider spi, instead of jmx

by Paul Ferraro (JIRA)

Modify jbossweb metrics to use service provider spi, instead of jmx ------------------------------------------------------------------- Key: MODCLUSTER-151 URL: https://jira.jboss.org/jira/browse/MODCLUSTER-151 Project: mod_cluster Issue Type: Feature Request Affects Versions: 1.1.0.CR1 Reporter: Paul Ferraro Assignee: Paul Ferraro Currently, the jbossweb load metrics (i.e. ActiveSessionsLoadMetric, BusyConnectorsLoadMetric, RequestCountLoadMetric, ReceiveTrafficLoadMetric, SendTrafficLoadMetric) use jmx to generate their load values. This is potentially fragile. Instead, these load metrics should use org.jboss.mod_cluster.Engine as a load context. This raises the issue of load value scope. Currently, load is scoped to a server. Really, this should be scoped to an engine. While server:engine is usually a 1:1 relationship, this is technically a 1:N relationship. Suggested API change: class LoadMetricSource<C extends LoadContext> { C createContext(Engine engine); } Where there exists: class EngineLoadMetricSource<EngineLoadContext> { public EngineLoadContext createContext(Engine engine) { return new EngineLoadContext(engine); } } class EngineLoadContext implements LoadContext { private final Engine engine; public EngineLoadContext(Engine engine) { this.engine = engine; } public Engine getEngine() { return this.engine; } public void close() { // Nothing to close } } The various jbossweb load metrics would use this source. -- 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

6
6
0 / 0

[JBoss JIRA] Created: (MODCLUSTER-112) Refactor project into modules for HA, catalina, core, etc.

by Paul Ferraro (JIRA)

Refactor project into modules for HA, catalina, core, etc. ---------------------------------------------------------- Key: MODCLUSTER-112 URL: https://jira.jboss.org/jira/browse/MODCLUSTER-112 Project: mod_cluster Issue Type: Sub-task Reporter: Paul Ferraro Assignee: Jean-Frederic Clere Restructure maven project to create separate module jars. mod-cluster-spi: ContainerEventHandler, Server, Engine, Connector, Host, Context mod-cluster-core: ModClusterService and dependencies mod-cluster-ha: HAModClusterService and dependencies mod-cluster-catalina: ModClusterListener, CatalinaEventHandlerAdapter and spi implementation -- 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
2
0 / 0

[JBoss JIRA] Created: (MODCLUSTER-105) Refactor mod_cluster to allow implementations for other application servers

by Paul Ferraro (JIRA)

Refactor mod_cluster to allow implementations for other application servers --------------------------------------------------------------------------- Key: MODCLUSTER-105 URL: https://jira.jboss.org/jira/browse/MODCLUSTER-105 Project: mod_cluster Issue Type: Feature Request Affects Versions: 1.0.2.GA Reporter: Paul Ferraro Assignee: Paul Ferraro Split current jar into a -core.jar containing APIs, and isolate catalina implementation to a separate -catalina.jar. -- 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
1
0 / 0

[JBoss JIRA] Created: (MODCLUSTER-183) NPE when overriding default load metric in ModClusterListener

by Paul Ferraro (JIRA)

NPE when overriding default load metric in ModClusterListener ------------------------------------------------------------- Key: MODCLUSTER-183 URL: https://jira.jboss.org/browse/MODCLUSTER-183 Project: mod_cluster Issue Type: Bug Affects Versions: 1.1.0.CR3 Reporter: Paul Ferraro Assignee: Paul Ferraro Fix For: 1.1.1.Final Tomcat/JBW's IntrospectionUtils doesn't handle properties of type Class. Consequently, if you try to override the loadMetricClass, you end up with a NullPointerException during startup, since the property value is read as a null. This property needs to be a String, rather than a Class. -- 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, 6 months

3
6
0 / 0

[JBoss JIRA] Created: (MODCLUSTER-184) Redeployment of application in Tomcat fails

by Ruslan Gainutdinov (JIRA)

Redeployment of application in Tomcat fails ------------------------------------------- Key: MODCLUSTER-184 URL: https://jira.jboss.org/browse/MODCLUSTER-184 Project: mod_cluster Issue Type: Bug Affects Versions: 1.1.0.Final Environment: Windows 7 x64, Java 1.6.0_18-b07 32bit, Tomcat 6.0.29 + APR 1.1.20 + load-demo.war manually unpacked into webapps/ folder. Reporter: Ruslan Gainutdinov Assignee: Jean-Frederic Clere Both methods of redeployment cause this error, either by pressing reload link in Tomcat manager webapp and by touching web.xml in load-demo webapplication. Log excerpt: 31.08.2010 10:30:41 org.apache.catalina.core.StandardContext reload INFO: Reloading this Context has started 31.08.2010 10:30:41 org.jboss.modcluster.ModClusterService DEBUG: Stop context [/load-demo] in host [localhost] 31.08.2010 10:30:41 org.jboss.modcluster.ModClusterService DEBUG: Start context [/load-demo] in host [localhost] 31.08.2010 10:30:41 org.apache.catalina.core.StandardPipeline registerValve INFO: Can't register valve org.jboss.modcluster.catalina.CatalinaContext$RequestListenerValve[/load-demo] java.lang.NoClassDefFoundError: org/jboss/servlet/http/HttpEvent at java.lang.Class.getDeclaredMethods0(Native Method) at java.lang.Class.privateGetDeclaredMethods(Class.java:2427) at java.lang.Class.privateGetPublicMethods(Class.java:2547) at java.lang.Class.getMethods(Class.java:1410) at org.apache.tomcat.util.modeler.modules.MbeansDescriptorsIntrospectionSource.createManagedBean(MbeansDescriptorsIntrospectionSource.java:304) at org.apache.tomcat.util.modeler.modules.MbeansDescriptorsIntrospectionSource.execute(MbeansDescriptorsIntrospectionSource.java:84) at org.apache.tomcat.util.modeler.modules.MbeansDescriptorsIntrospectionSource.loadDescriptors(MbeansDescriptorsIntrospectionSource.java:77) at org.apache.tomcat.util.modeler.Registry.load(Registry.java:754) at org.apache.tomcat.util.modeler.Registry.loadDescriptors(Registry.java:866) at org.apache.tomcat.util.modeler.Registry.findManagedBean(Registry.java:651) at org.apache.tomcat.util.modeler.Registry.findManagedBean(Registry.java:963) at org.apache.tomcat.util.modeler.Registry.registerComponent(Registry.java:794) at org.apache.catalina.core.StandardPipeline.registerValve(StandardPipeline.java:302) at org.apache.catalina.core.StandardPipeline.addValve(StandardPipeline.java:448) at org.jboss.modcluster.catalina.CatalinaContext.addRequestListener(CatalinaContext.java:114) at org.jboss.modcluster.ModClusterService.start(ModClusterService.java:385) at org.jboss.modcluster.catalina.CatalinaEventHandlerAdapter.lifecycleEvent(CatalinaEventHandlerAdapter.java:257) at org.apache.catalina.util.LifecycleSupport.fireLifecycleEvent(LifecycleSupport.java:119) at org.apache.catalina.core.StandardContext.start(StandardContext.java:4540) at org.apache.catalina.core.StandardContext.reload(StandardContext.java:3391) at org.apache.catalina.manager.ManagerServlet.reload(ManagerServlet.java:943) at org.apache.catalina.manager.HTMLManagerServlet.reload(HTMLManagerServlet.java:556) at org.apache.catalina.manager.HTMLManagerServlet.doGet(HTMLManagerServlet.java:121) at javax.servlet.http.HttpServlet.service(HttpServlet.java:617) at javax.servlet.http.HttpServlet.service(HttpServlet.java:717) at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:290) at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:206) at org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:233) at org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:191) at org.apache.catalina.authenticator.AuthenticatorBase.invoke(AuthenticatorBase.java:563) at org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:127) at org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:102) at org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:109) at org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:298) at org.apache.coyote.http11.Http11AprProcessor.process(Http11AprProcessor.java:861) at org.apache.coyote.http11.Http11AprProtocol$Http11ConnectionHandler.process(Http11AprProtocol.java:579) at org.apache.tomcat.util.net.AprEndpoint$Worker.run(AprEndpoint.java:1584) at java.lang.Thread.run(Thread.java:619) Caused by: java.lang.ClassNotFoundException: org.jboss.servlet.http.HttpEvent at java.net.URLClassLoader$1.run(URLClassLoader.java:202) at java.security.AccessController.doPrivileged(Native Method) at java.net.URLClassLoader.findClass(URLClassLoader.java:190) at java.lang.ClassLoader.loadClass(ClassLoader.java:307) at java.lang.ClassLoader.loadClass(ClassLoader.java:248) ... 38 more As I can see, it is caused by wrong method signature in class org.jboss.modcluster.catalina.CatalinaContext.RequestListenerValve public void event(Request request, Response response, HttpEvent event) throws IOException, ServletException -- 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, 8 months

2
1
0 / 0

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

mod_cluster-issues August 2010