[JBoss JIRA] (MODCLUSTER-152) Redeploy EAR with @WebService annotated beans cause 404
by Michal Babacek (JIRA)
[ https://issues.jboss.org/browse/MODCLUSTER-152?page=com.atlassian.jira.pl... ]
Michal Babacek closed MODCLUSTER-152.
-------------------------------------
Closing. Clean-up.
At least one of the following applies:
* the issue has been thoroughly tested as a part of one of the current releases
or
* it hasn't occurred in ~2 years
or
* it's utterly harmless
> Redeploy EAR with @WebService annotated beans cause 404
> -------------------------------------------------------
>
> Key: MODCLUSTER-152
> URL: https://issues.jboss.org/browse/MODCLUSTER-152
> Project: mod_cluster
> Issue Type: Bug
> Security Level: Public(Everyone can see)
> Affects Versions: 1.0.3.GA, 1.1.0.CR1
> 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: Gabor Auth
> Assignee: Jean-Frederic Clere
> Attachments: Common-test.zip, Test-1.0.0.jar
>
>
> 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 was sent by Atlassian JIRA
(v6.2.6#6264)
9 years, 9 months
[JBoss JIRA] (MODCLUSTER-147) Failover doesn't work
by Michal Babacek (JIRA)
[ https://issues.jboss.org/browse/MODCLUSTER-147?page=com.atlassian.jira.pl... ]
Michal Babacek closed MODCLUSTER-147.
-------------------------------------
Closing. Clean-up.
At least one of the following applies:
* the issue has been thoroughly tested as a part of one of the current releases
or
* it hasn't occurred in ~2 years
or
* it's utterly harmless
> Failover doesn't work
> ---------------------
>
> Key: MODCLUSTER-147
> URL: https://issues.jboss.org/browse/MODCLUSTER-147
> Project: mod_cluster
> Issue Type: Bug
> Security Level: Public(Everyone can see)
> Affects Versions: 1.1.0.CR1
> Reporter: Bela Ban
> Assignee: Jean-Frederic Clere
> Fix For: 1.1.0.CR2
>
>
> 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 was sent by Atlassian JIRA
(v6.2.6#6264)
9 years, 9 months
[JBoss JIRA] (MODCLUSTER-64) mod_cluster-manager status page reports wrong information.
by Michal Babacek (JIRA)
[ https://issues.jboss.org/browse/MODCLUSTER-64?page=com.atlassian.jira.plu... ]
Michal Babacek closed MODCLUSTER-64.
------------------------------------
Closing. Clean-up.
At least one of the following applies:
* the issue has been thoroughly tested as a part of one of the current releases
or
* it hasn't occurred in ~2 years
or
* it's utterly harmless
> mod_cluster-manager status page reports wrong information.
> ----------------------------------------------------------
>
> Key: MODCLUSTER-64
> URL: https://issues.jboss.org/browse/MODCLUSTER-64
> Project: mod_cluster
> Issue Type: Bug
> Security Level: Public(Everyone can see)
> Environment: Any
> Reporter: Jean-Frederic Clere
> Assignee: Jean-Frederic Clere
> Fix For: 1.0.0.CR1
>
>
> The mod_cluster-manager status page reports Transfered: 0, Connected: 0, Load: 0 Num sessions: 0 for all nodes, always; doesn't ever report actual data.
> Also "Transfered" should be "Transferred"
--
This message was sent by Atlassian JIRA
(v6.2.6#6264)
9 years, 9 months
[JBoss JIRA] (MODCLUSTER-259) Load-demo application does not work with AS7
by Michal Babacek (JIRA)
[ https://issues.jboss.org/browse/MODCLUSTER-259?page=com.atlassian.jira.pl... ]
Michal Babacek closed MODCLUSTER-259.
-------------------------------------
Closing. Clean-up.
At least one of the following applies:
* the issue has been thoroughly tested as a part of one of the current releases
or
* it hasn't occurred in ~2 years
or
* it's utterly harmless
> Load-demo application does not work with AS7
> ---------------------------------------------
>
> Key: MODCLUSTER-259
> URL: https://issues.jboss.org/browse/MODCLUSTER-259
> Project: mod_cluster
> Issue Type: Bug
> Security Level: Public(Everyone can see)
> Affects Versions: 1.1.2.Final , 1.1.3.Final
> Reporter: Michal Babacek
> Assignee: Jean-Frederic Clere
> Priority: Blocker
> Labels: mod_cluster
> Fix For: 1.2.0.Beta2
>
>
> It is not possible to use the [Load-demo application|http://bit.ly/qbRyC5] with AS7 7.1.0-SNAPSHOT.
> It appears that LoadServlet is looking for things in JMX that aren't in JMX anymore in AS7, as [~brian.stansberry ] confirmed.
> {code:java}
> 14:32:55,851 INFO [org.jboss.as.server.controller] (DeploymentScanner-threads - 2) Deployed "load-demo.war"
> 14:33:01,880 INFO [org.jboss.modcluster.ModClusterService] (ContainerBackgroundProcessor[StandardEngine[jboss.web]]) Engine [jboss.web] will use jvmRoute: 01node
> 14:33:01,987 ERROR [org.apache.catalina.core.ContainerBase.[jboss.web].[default-host].[/load-demo]] (http--127.0.0.1-8080-2) StandardWrapper.Throwable: java.lang.NoClassDefFoundError: org/apache/catalina/ServerFactory
> at org.jboss.modcluster.demo.servlet.LoadServlet.findService(Unknown Source) [classes:]
> at org.jboss.modcluster.demo.servlet.LoadServlet.init(Unknown Source) [classes:]
> at org.apache.catalina.core.StandardWrapper.loadServlet(StandardWrapper.java:1202) [jbossweb-7.0.1.Final.jar:7.1.0.Alpha1-SNAPSHOT]
> at org.apache.catalina.core.StandardWrapper.allocate(StandardWrapper.java:952) [jbossweb-7.0.1.Final.jar:7.1.0.Alpha1-SNAPSHOT]
> at org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:188) [jbossweb-7.0.1.Final.jar:7.1.0.Alpha1-SNAPSHOT]
> at org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:161) [jbossweb-7.0.1.Final.jar:7.1.0.Alpha1-SNAPSHOT]
> at org.jboss.as.web.security.SecurityContextAssociationValve.invoke(SecurityContextAssociationValve.java:139) [jboss-as-web-7.1.0.Alpha1-SNAPSHOT.jar:7.1.0.Alpha1-SNAPSHOT]
> at org.jboss.modcluster.catalina.CatalinaContext$RequestListenerValve.event(CatalinaContext.java:285)
> at org.jboss.modcluster.catalina.CatalinaContext$RequestListenerValve.invoke(CatalinaContext.java:261)
> at org.jboss.as.web.session.ClusteredSessionValve.handleRequest(ClusteredSessionValve.java:123) [jboss-as-web-7.1.0.Alpha1-SNAPSHOT.jar:7.1.0.Alpha1-SNAPSHOT]
> at org.jboss.as.web.session.ClusteredSessionValve.invoke(ClusteredSessionValve.java:89) [jboss-as-web-7.1.0.Alpha1-SNAPSHOT.jar:7.1.0.Alpha1-SNAPSHOT]
> at org.jboss.as.web.session.JvmRouteValve.invoke(JvmRouteValve.java:88) [jboss-as-web-7.1.0.Alpha1-SNAPSHOT.jar:7.1.0.Alpha1-SNAPSHOT]
> at org.jboss.as.web.session.LockingValve.invoke(LockingValve.java:56) [jboss-as-web-7.1.0.Alpha1-SNAPSHOT.jar:7.1.0.Alpha1-SNAPSHOT]
> at org.jboss.as.web.session.ClusteredSessionValve.handleRequest(ClusteredSessionValve.java:123) [jboss-as-web-7.1.0.Alpha1-SNAPSHOT.jar:7.1.0.Alpha1-SNAPSHOT]
> at org.jboss.as.web.session.ClusteredSessionValve.invoke(ClusteredSessionValve.java:89) [jboss-as-web-7.1.0.Alpha1-SNAPSHOT.jar:7.1.0.Alpha1-SNAPSHOT]
> at org.jboss.as.web.session.JvmRouteValve.invoke(JvmRouteValve.java:88) [jboss-as-web-7.1.0.Alpha1-SNAPSHOT.jar:7.1.0.Alpha1-SNAPSHOT]
> at org.jboss.as.web.session.LockingValve.invoke(LockingValve.java:56) [jboss-as-web-7.1.0.Alpha1-SNAPSHOT.jar:7.1.0.Alpha1-SNAPSHOT]
> at org.jboss.as.web.NamingValve.invoke(NamingValve.java:57) [jboss-as-web-7.1.0.Alpha1-SNAPSHOT.jar:7.1.0.Alpha1-SNAPSHOT]
> at org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:154) [jbossweb-7.0.1.Final.jar:7.1.0.Alpha1-SNAPSHOT]
> at org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:102) [jbossweb-7.0.1.Final.jar:7.1.0.Alpha1-SNAPSHOT]
> at org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:109) [jbossweb-7.0.1.Final.jar:7.1.0.Alpha1-SNAPSHOT]
> at org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:362) [jbossweb-7.0.1.Final.jar:7.1.0.Alpha1-SNAPSHOT]
> at org.apache.coyote.http11.Http11Processor.process(Http11Processor.java:877) [jbossweb-7.0.1.Final.jar:7.1.0.Alpha1-SNAPSHOT]
> at org.apache.coyote.http11.Http11Protocol$Http11ConnectionHandler.process(Http11Protocol.java:667) [jbossweb-7.0.1.Final.jar:7.1.0.Alpha1-SNAPSHOT]
> at org.apache.tomcat.util.net.JIoEndpoint$Worker.run(JIoEndpoint.java:952) [jbossweb-7.0.1.Final.jar:7.1.0.Alpha1-SNAPSHOT]
> at java.lang.Thread.run(Thread.java:662) [:1.6.0_24]
> Caused by: java.lang.ClassNotFoundException: org.apache.catalina.ServerFactory from [Module "deployment.load-demo.war:main" from Service Module Loader]
> at org.jboss.modules.ModuleClassLoader.findClass(ModuleClassLoader.java:191)
> at org.jboss.modules.ConcurrentClassLoader.performLoadClassChecked(ConcurrentClassLoader.java:361)
> at org.jboss.modules.ConcurrentClassLoader.performLoadClassChecked(ConcurrentClassLoader.java:333)
> at org.jboss.modules.ConcurrentClassLoader.performLoadClass(ConcurrentClassLoader.java:310)
> at org.jboss.modules.ConcurrentClassLoader.loadClass(ConcurrentClassLoader.java:103)
> ... 26 more
> 14:33:01,989 ERROR [org.apache.catalina.core.ContainerBase.[jboss.web].[default-host].[/load-demo].[record]] (http--127.0.0.1-8080-2) Allocate exception for servlet record: java.lang.ClassNotFoundException: org.apache.catalina.ServerFactory from [Module "deployment.load-demo.war:main" from Service Module Loader]
> at org.jboss.modules.ModuleClassLoader.findClass(ModuleClassLoader.java:191)
> at org.jboss.modules.ConcurrentClassLoader.performLoadClassChecked(ConcurrentClassLoader.java:361)
> at org.jboss.modules.ConcurrentClassLoader.performLoadClassChecked(ConcurrentClassLoader.java:333)
> at org.jboss.modules.ConcurrentClassLoader.performLoadClass(ConcurrentClassLoader.java:310)
> at org.jboss.modules.ConcurrentClassLoader.loadClass(ConcurrentClassLoader.java:103)
> at org.jboss.modcluster.demo.servlet.LoadServlet.findService(Unknown Source) [classes:]
> at org.jboss.modcluster.demo.servlet.LoadServlet.init(Unknown Source) [classes:]
> at org.apache.catalina.core.StandardWrapper.loadServlet(StandardWrapper.java:1202) [jbossweb-7.0.1.Final.jar:7.1.0.Alpha1-SNAPSHOT]
> at org.apache.catalina.core.StandardWrapper.allocate(StandardWrapper.java:952) [jbossweb-7.0.1.Final.jar:7.1.0.Alpha1-SNAPSHOT]
> at org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:188) [jbossweb-7.0.1.Final.jar:7.1.0.Alpha1-SNAPSHOT]
> at org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:161) [jbossweb-7.0.1.Final.jar:7.1.0.Alpha1-SNAPSHOT]
> at org.jboss.as.web.security.SecurityContextAssociationValve.invoke(SecurityContextAssociationValve.java:139) [jboss-as-web-7.1.0.Alpha1-SNAPSHOT.jar:7.1.0.Alpha1-SNAPSHOT]
> at org.jboss.modcluster.catalina.CatalinaContext$RequestListenerValve.event(CatalinaContext.java:285)
> at org.jboss.modcluster.catalina.CatalinaContext$RequestListenerValve.invoke(CatalinaContext.java:261)
> at org.jboss.as.web.session.ClusteredSessionValve.handleRequest(ClusteredSessionValve.java:123) [jboss-as-web-7.1.0.Alpha1-SNAPSHOT.jar:7.1.0.Alpha1-SNAPSHOT]
> at org.jboss.as.web.session.ClusteredSessionValve.invoke(ClusteredSessionValve.java:89) [jboss-as-web-7.1.0.Alpha1-SNAPSHOT.jar:7.1.0.Alpha1-SNAPSHOT]
> at org.jboss.as.web.session.JvmRouteValve.invoke(JvmRouteValve.java:88) [jboss-as-web-7.1.0.Alpha1-SNAPSHOT.jar:7.1.0.Alpha1-SNAPSHOT]
> at org.jboss.as.web.session.LockingValve.invoke(LockingValve.java:56) [jboss-as-web-7.1.0.Alpha1-SNAPSHOT.jar:7.1.0.Alpha1-SNAPSHOT]
> at org.jboss.as.web.session.ClusteredSessionValve.handleRequest(ClusteredSessionValve.java:123) [jboss-as-web-7.1.0.Alpha1-SNAPSHOT.jar:7.1.0.Alpha1-SNAPSHOT]
> at org.jboss.as.web.session.ClusteredSessionValve.invoke(ClusteredSessionValve.java:89) [jboss-as-web-7.1.0.Alpha1-SNAPSHOT.jar:7.1.0.Alpha1-SNAPSHOT]
> at org.jboss.as.web.session.JvmRouteValve.invoke(JvmRouteValve.java:88) [jboss-as-web-7.1.0.Alpha1-SNAPSHOT.jar:7.1.0.Alpha1-SNAPSHOT]
> at org.jboss.as.web.session.LockingValve.invoke(LockingValve.java:56) [jboss-as-web-7.1.0.Alpha1-SNAPSHOT.jar:7.1.0.Alpha1-SNAPSHOT]
> at org.jboss.as.web.NamingValve.invoke(NamingValve.java:57) [jboss-as-web-7.1.0.Alpha1-SNAPSHOT.jar:7.1.0.Alpha1-SNAPSHOT]
> at org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:154) [jbossweb-7.0.1.Final.jar:7.1.0.Alpha1-SNAPSHOT]
> at org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:102) [jbossweb-7.0.1.Final.jar:7.1.0.Alpha1-SNAPSHOT]
> at org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:109) [jbossweb-7.0.1.Final.jar:7.1.0.Alpha1-SNAPSHOT]
> at org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:362) [jbossweb-7.0.1.Final.jar:7.1.0.Alpha1-SNAPSHOT]
> at org.apache.coyote.http11.Http11Processor.process(Http11Processor.java:877) [jbossweb-7.0.1.Final.jar:7.1.0.Alpha1-SNAPSHOT]
> at org.apache.coyote.http11.Http11Protocol$Http11ConnectionHandler.process(Http11Protocol.java:667) [jbossweb-7.0.1.Final.jar:7.1.0.Alpha1-SNAPSHOT]
> at org.apache.tomcat.util.net.JIoEndpoint$Worker.run(JIoEndpoint.java:952) [jbossweb-7.0.1.Final.jar:7.1.0.Alpha1-SNAPSHOT]
> at java.lang.Thread.run(Thread.java:662) [:1.6.0_24]
> {code}
> It is quite crucial for Mod_cluster + AS7 testing to have this fixed somehow :)
--
This message was sent by Atlassian JIRA
(v6.2.6#6264)
9 years, 9 months
[JBoss JIRA] (MODCLUSTER-103) Skip load balance factor calculation if there are no proxies to receive status message
by Michal Babacek (JIRA)
[ https://issues.jboss.org/browse/MODCLUSTER-103?page=com.atlassian.jira.pl... ]
Michal Babacek closed MODCLUSTER-103.
-------------------------------------
Closing. Clean-up.
At least one of the following applies:
* the issue has been thoroughly tested as a part of one of the current releases
or
* it hasn't occurred in ~2 years
or
* it's utterly harmless
> Skip load balance factor calculation if there are no proxies to receive status message
> --------------------------------------------------------------------------------------
>
> Key: MODCLUSTER-103
> URL: https://issues.jboss.org/browse/MODCLUSTER-103
> Project: mod_cluster
> Issue Type: Feature Request
> Security Level: Public(Everyone can see)
> Affects Versions: 1.0.2.GA
> Reporter: Paul Ferraro
> Assignee: Paul Ferraro
> Priority: Minor
> Fix For: 1.1.0.CR1
>
>
> To keep MCMPHandler.status() as lightweight as possible if there are no proxies with which to communicate, we can skip load balance factor calculation altogether.
--
This message was sent by Atlassian JIRA
(v6.2.6#6264)
9 years, 9 months
[JBoss JIRA] (MODCLUSTER-62) HeapMemoryUsageLoadMetric fails if max heap is undefined
by Michal Babacek (JIRA)
[ https://issues.jboss.org/browse/MODCLUSTER-62?page=com.atlassian.jira.plu... ]
Michal Babacek closed MODCLUSTER-62.
------------------------------------
Closing. Clean-up.
At least one of the following applies:
* the issue has been thoroughly tested as a part of one of the current releases
or
* it hasn't occurred in ~2 years
or
* it's utterly harmless
> HeapMemoryUsageLoadMetric fails if max heap is undefined
> --------------------------------------------------------
>
> Key: MODCLUSTER-62
> URL: https://issues.jboss.org/browse/MODCLUSTER-62
> Project: mod_cluster
> Issue Type: Bug
> Security Level: Public(Everyone can see)
> Affects Versions: 1.0.0.Beta4
> Reporter: Paul Ferraro
> Assignee: Paul Ferraro
> Priority: Minor
> Fix For: 1.0.0.CR1
>
>
> java.lang.management.MemoryUsage.getMax() can return -1 if the max heap size is undefined.
> HeapMemoryUsageLoadMetric does not handle this condition - and will return anomalous results.
--
This message was sent by Atlassian JIRA
(v6.2.6#6264)
9 years, 9 months
[JBoss JIRA] (MODCLUSTER-47) Master node enters tight loop calling getClusterCoordinatorState on remote node
by Michal Babacek (JIRA)
[ https://issues.jboss.org/browse/MODCLUSTER-47?page=com.atlassian.jira.plu... ]
Michal Babacek closed MODCLUSTER-47.
------------------------------------
Closing. Clean-up.
At least one of the following applies:
* the issue has been thoroughly tested as a part of one of the current releases
or
* it hasn't occurred in ~2 years
or
* it's utterly harmless
> Master node enters tight loop calling getClusterCoordinatorState on remote node
> -------------------------------------------------------------------------------
>
> Key: MODCLUSTER-47
> URL: https://issues.jboss.org/browse/MODCLUSTER-47
> Project: mod_cluster
> Issue Type: Bug
> Security Level: Public(Everyone can see)
> Affects Versions: 1.0.0.Beta3
> Reporter: Brian Stansberry
> Assignee: Paul Ferraro
> Priority: Critical
> Fix For: 1.0.0.Beta4
>
> Attachments: node1-modha.log, node2-modha.log
>
>
> To reproduce:
> 1) Install the mod_cluster 1.0.0.Beta3 sar on two nodes.
> 2) Configure a value for the proxyList config (don't know if this is relevant, just the way my setup is)
> 3) Add a war that's not excluded to both nodes
> 4) Start node1
> 5) Start node2
> After node2 starts, node1's background thread goes into a loop calling getCoordinatorState on the other node, repeating as soon as a response is received:
> 2009-02-03 16:36:08,120 DEBUG [org.jboss.modcluster.ha.HAModClusterService] (ContainerBackgroundProcessor[StandardEngine[jboss.web]]) Check status for engine [jboss.web]
> 2009-02-03 16:36:08,122 TRACE [org.jboss.ha.framework.interfaces.HAPartition.DefaultPartition] (ContainerBackgroundProcessor[StandardEngine[jboss.web]]) callMethodOnCluster(true), objName=HAModClusterService, methodName=getClusterCoordinatorState, members=[192.168.1.146:58895]
> 2009-02-03 16:36:08,125 TRACE [org.jboss.ha.framework.server.ClusterPartition$RpcHandler] (ContainerBackgroundProcessor[StandardEngine[jboss.web]]) dests=[192.168.1.146:58895], method_call=HAModClusterService.getClusterCoordinatorState([MCMPServerStateImpl{address=/127.0.0.1,port=6666,state=OK,establishedtrue}]), mode=2, timeout=60000
> 2009-02-03 16:36:08,126 TRACE [org.jboss.ha.framework.server.ClusterPartition$RpcHandler] (ContainerBackgroundProcessor[StandardEngine[jboss.web]]) real_dests=[192.168.1.146:58895]
> 2009-02-03 16:36:08,184 TRACE [org.jboss.ha.framework.server.ClusterPartition$RpcHandler] (ContainerBackgroundProcessor[StandardEngine[jboss.web]]) responses: [sender=192.168.1.146:58895, retval=org.jboss.modcluster.ha.rpc.ModClusterServiceStateGroupRpcResponse@37bb7c19, received=true, suspected=false]
> 2009-02-03 16:36:08,187 TRACE [org.jboss.ha.framework.interfaces.HAPartition.DefaultPartition] (ContainerBackgroundProcessor[StandardEngine[jboss.web]]) callMethodOnCluster(true), objName=HAModClusterService, methodName=getClusterCoordinatorState, members=[192.168.1.146:58895]
> 2009-02-03 16:36:08,187 TRACE [org.jboss.ha.framework.server.ClusterPartition$RpcHandler] (ContainerBackgroundProcessor[StandardEngine[jboss.web]]) dests=[192.168.1.146:58895], method_call=HAModClusterService.getClusterCoordinatorState([MCMPServerStateImpl{address=/127.0.0.1,port=6666,state=OK,establishedtrue}]), mode=2, timeout=60000
> 2009-02-03 16:36:08,187 TRACE [org.jboss.ha.framework.server.ClusterPartition$RpcHandler] (ContainerBackgroundProcessor[StandardEngine[jboss.web]]) real_dests=[192.168.1.146:58895]
> 2009-02-03 16:36:08,199 TRACE [org.jboss.ha.framework.server.ClusterPartition$RpcHandler] (ContainerBackgroundProcessor[StandardEngine[jboss.web]]) responses: [sender=192.168.1.146:58895, retval=org.jboss.modcluster.ha.rpc.ModClusterServiceStateGroupRpcResponse@1d64d42f, received=true, suspected=false]
> 2009-02-03 16:36:08,199 TRACE [org.jboss.ha.framework.interfaces.HAPartition.DefaultPartition] (ContainerBackgroundProcessor[StandardEngine[jboss.web]]) callMethodOnCluster(true), objName=HAModClusterService, methodName=getClusterCoordinatorState, members=[192.168.1.146:58895]
> and so on
--
This message was sent by Atlassian JIRA
(v6.2.6#6264)
9 years, 9 months
[JBoss JIRA] (MODCLUSTER-4) Intra-clustering communication component for mod_cluster
by Michal Babacek (JIRA)
[ https://issues.jboss.org/browse/MODCLUSTER-4?page=com.atlassian.jira.plug... ]
Michal Babacek closed MODCLUSTER-4.
-----------------------------------
Closing. Clean-up.
> Intra-clustering communication component for mod_cluster
> --------------------------------------------------------
>
> Key: MODCLUSTER-4
> URL: https://issues.jboss.org/browse/MODCLUSTER-4
> Project: mod_cluster
> Issue Type: Feature Request
> Security Level: Public(Everyone can see)
> Reporter: Brian Stansberry
> Assignee: Paul Ferraro
> Fix For: 1.0.0.Beta1
>
>
> Communication component that handles intra-cluster communication within the AS instances, aggregates information and passes to the component that communicates with mod_cluster on the httpd side.
> Tracks cluster membership. A node (one per cluster) or set of nodes (one per domain) are determined to be master.
> All nodes receive events from a listener layer indicating deployments, JBossWeb Server start and stop etc. Pass those one to their master via RPCs. All nodes also respond to periodic RPCs from master node asking for load information.
> Master node(s) inform httpd side about events that are received. Periodically request load information from nodes, aggregate into overall load factors and provide to mod_cluster via STATUS messages. Inform mod_cluster about topology changes (crashed members, etc).
> Initial expectation is this will be based upon HASingletonSupport class.
--
This message was sent by Atlassian JIRA
(v6.2.6#6264)
9 years, 9 months