August 2014 - mod_cluster-issues - Jboss List Archives

[JBoss JIRA] (MODCLUSTER-15) LoadMetricSource impl for gathering JBossWeb session metrics

by Michal Babacek (JIRA)

[ https://issues.jboss.org/browse/MODCLUSTER-15?page=com.atlassian.jira.plu... ] Michal Babacek closed MODCLUSTER-15. ------------------------------------ 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 > LoadMetricSource impl for gathering JBossWeb session metrics > ------------------------------------------------------------ > > Key: MODCLUSTER-15 > URL: https://issues.jboss.org/browse/MODCLUSTER-15 > Project: mod_cluster > Issue Type: Sub-task > Security Level: Public(Everyone can see) > Components: Clustering, Web (Tomcat) service > Reporter: Brian Stansberry > Assignee: Paul Ferraro > > Gather metrics about numbers of sessions and related statistics. -- This message was sent by Atlassian JIRA (v6.2.6#6264)

9 years, 8 months

1
0
0 / 0

[JBoss JIRA] (MODCLUSTER-107) Service Temporarily Unavailable when the either node is killed

by Michal Babacek (JIRA)

[ https://issues.jboss.org/browse/MODCLUSTER-107?page=com.atlassian.jira.pl... ] Michal Babacek closed MODCLUSTER-107. ------------------------------------- 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 > Service Temporarily Unavailable when the either node is killed > -------------------------------------------------------------- > > Key: MODCLUSTER-107 > URL: https://issues.jboss.org/browse/MODCLUSTER-107 > Project: mod_cluster > Issue Type: Bug > Security Level: Public(Everyone can see) > Affects Versions: 1.0.2.GA > Environment: Windows Vista, Seam 2.2.0.GA, JBoss 5.1.0.GA, mod_cluster 1.0.2.GA(+httpd 2.2), > Reporter: bb bb > Assignee: Jean-Frederic Clere > > When I killed one node in clustered environment I get the following error in the browser, and the other nodes not serving the request > 503 > Service Temporarily Unavailable > The server is temporarily unable to service your request due to maintenance downtime or capacity problems. Please try again later. -- This message was sent by Atlassian JIRA (v6.2.6#6264)

9 years, 8 months

1
0
0 / 0

[JBoss JIRA] (MODCLUSTER-188) mod_cluster failover does not work for a /webappcontext when the / root context exists

by Michal Babacek (JIRA)

[ https://issues.jboss.org/browse/MODCLUSTER-188?page=com.atlassian.jira.pl... ] Michal Babacek closed MODCLUSTER-188. ------------------------------------- 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 failover does not work for a /webappcontext when the / root context exists > -------------------------------------------------------------------------------------- > > Key: MODCLUSTER-188 > URL: https://issues.jboss.org/browse/MODCLUSTER-188 > Project: mod_cluster > Issue Type: Bug > Security Level: Public(Everyone can see) > Affects Versions: 1.0.4.GA, 1.1.0.Beta1 > Reporter: Samuel Mendenhall > Assignee: Jean-Frederic Clere > Fix For: 1.0.8, 1.1.2.Final > > > Let's say for example that /webapp and / is mapped in mod_cluster and there are two JBoss instances. If in one JBoss instance you undeploy the /webapp, you would expect mod_cluster to failover to the other JBoss instance. > However, this is not the case, mod_cluster will instead select the lesser context, the root context / and service the request from /webapp on the / context. > The logic only tests for ENABLE and DISABLE the STOP is not tested. > The failover of a context will only work currently if / or any smaller path is not deployed -- This message was sent by Atlassian JIRA (v6.2.6#6264)

9 years, 8 months

1
0
0 / 0

[JBoss JIRA] (MODCLUSTER-236) Allow context lengths greater than 40

by Michal Babacek (JIRA)

[ https://issues.jboss.org/browse/MODCLUSTER-236?page=com.atlassian.jira.pl... ] Michal Babacek closed MODCLUSTER-236. ------------------------------------- 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 > Allow context lengths greater than 40 > ------------------------------------- > > Key: MODCLUSTER-236 > URL: https://issues.jboss.org/browse/MODCLUSTER-236 > Project: mod_cluster > Issue Type: Feature Request > Security Level: Public(Everyone can see) > Affects Versions: 1.1.2.Final > Reporter: Samuel Mendenhall > Assignee: Jean-Frederic Clere > Fix For: 1.2.0.Beta4 > > > The mod_cluster 1.1 documentation states the following in the Limitation section: > "Max context length 40 (for example myapp.war deploys in /myapp /myapp is the context)." > This value should be at least doubled to 80 for use with ESB which creates long context names. -- This message was sent by Atlassian JIRA (v6.2.6#6264)

9 years, 8 months

1
0
0 / 0

[JBoss JIRA] (MODCLUSTER-245) Calculate the MAXMESSSIZE dynamically

by Michal Babacek (JIRA)

[ https://issues.jboss.org/browse/MODCLUSTER-245?page=com.atlassian.jira.pl... ] Michal Babacek closed MODCLUSTER-245. ------------------------------------- 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 > Calculate the MAXMESSSIZE dynamically > ------------------------------------- > > Key: MODCLUSTER-245 > URL: https://issues.jboss.org/browse/MODCLUSTER-245 > Project: mod_cluster > Issue Type: Feature Request > Security Level: Public(Everyone can see) > Affects Versions: 1.1.2.Final > Reporter: Samuel Mendenhall > Assignee: Jean-Frederic Clere > Fix For: 1.2.0.Beta4 > > > Calculate the MAXMESSIZE dynamically at start time from the rest of the configuration. -- This message was sent by Atlassian JIRA (v6.2.6#6264)

9 years, 8 months

1
0
0 / 0

[JBoss JIRA] (MODCLUSTER-243) mod_cluster throws warnings at shutdown in AS7

by Michal Babacek (JIRA)

[ https://issues.jboss.org/browse/MODCLUSTER-243?page=com.atlassian.jira.pl... ] Michal Babacek closed MODCLUSTER-243. ------------------------------------- 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 throws warnings at shutdown in AS7 > ---------------------------------------------- > > Key: MODCLUSTER-243 > URL: https://issues.jboss.org/browse/MODCLUSTER-243 > Project: mod_cluster > Issue Type: Bug > Security Level: Public(Everyone can see) > Affects Versions: 1.1.2.Final > Reporter: Jean-Frederic Clere > Assignee: Jean-Frederic Clere > Priority: Minor > Fix For: 1.2.0.Beta1 > > > At shutdown you get an warning: > +++ > 21:37:37,537 WARN [org.jboss.modcluster.advertise.impl.AdvertiseListenerImpl] (MSC service thread 1-1) Failed to interrupt socket reception: java.io.IOException: Invalid argument > at java.net.PlainDatagramSocketImpl.send(Native Method) [:1.6.0_22] > at java.net.DatagramSocket.send(DatagramSocket.java:629) [:1.6.0_22] > at org.jboss.modcluster.advertise.impl.AdvertiseListenerImpl.interruptDatagramReader(AdvertiseListenerImpl.java:240) > at org.jboss.modcluster.advertise.impl.AdvertiseListenerImpl.stop(AdvertiseListenerImpl.java:262) > at org.jboss.modcluster.advertise.impl.AdvertiseListenerImpl.destroy(AdvertiseListenerImpl.java:278) > at org.jboss.modcluster.ModClusterService.shutdown(ModClusterService.java:214) > at org.jboss.modcluster.catalina.CatalinaEventHandlerAdapter.destroy(CatalinaEventHandlerAdapter.java:374) > at org.jboss.modcluster.catalina.CatalinaEventHandlerAdapter.stop(CatalinaEventHandlerAdapter.java:144) > at org.jboss.as.modcluster.ModClusterService.stop(ModClusterService.java:236) > at org.jboss.msc.service.ServiceControllerImpl$StopTask.run(ServiceControllerImpl.java:1819) > at org.jboss.msc.service.ServiceControllerImpl$ClearTCCLTask.run(ServiceControllerImpl.java:2302) > at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1110) [:1.6.0_22] > at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:603) [:1.6.0_22] > at java.lang.Thread.run(Thread.java:679) [:1.6.0_22] > +++ > In fact that should be a debug... And the fix should go in mod_cluster. -- This message was sent by Atlassian JIRA (v6.2.6#6264)

9 years, 8 months

1
0
0 / 0

[JBoss JIRA] (MODCLUSTER-218) CLONE - Make mod_cluster manager tolerant to F5 page refresh when disabled context

by Michal Babacek (JIRA)

[ https://issues.jboss.org/browse/MODCLUSTER-218?page=com.atlassian.jira.pl... ] Michal Babacek closed MODCLUSTER-218. ------------------------------------- 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 > CLONE - Make mod_cluster manager tolerant to F5 page refresh when disabled context > ---------------------------------------------------------------------------------- > > Key: MODCLUSTER-218 > URL: https://issues.jboss.org/browse/MODCLUSTER-218 > Project: mod_cluster > Issue Type: Feature Request > Security Level: Public(Everyone can see) > Affects Versions: 1.0.2.GA > Reporter: Radoslav Husar > Assignee: Jean-Frederic Clere > Priority: Minor > Fix For: 1.0.10 > > > 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 was sent by Atlassian JIRA (v6.2.6#6264)

9 years, 8 months

1
0
0 / 0

[JBoss JIRA] (MODCLUSTER-244) Increase the MAXMESSSIZE and allow it to be configurable via a parameter

by Michal Babacek (JIRA)

[ https://issues.jboss.org/browse/MODCLUSTER-244?page=com.atlassian.jira.pl... ] Michal Babacek closed MODCLUSTER-244. ------------------------------------- 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 > Increase the MAXMESSSIZE and allow it to be configurable via a parameter > ------------------------------------------------------------------------ > > Key: MODCLUSTER-244 > URL: https://issues.jboss.org/browse/MODCLUSTER-244 > Project: mod_cluster > Issue Type: Feature Request > Security Level: Public(Everyone can see) > Affects Versions: 1.0.10, 1.1.3.Final > Reporter: Samuel Mendenhall > Assignee: Jean-Frederic Clere > Fix For: 1.2.0.Beta4 > > > The MCMP message size, MAXMESSSIZE, is a constant fixed to 1024 bytes. The MAXMESSSIZE should be increased and also configurable via a parameter. -- This message was sent by Atlassian JIRA (v6.2.6#6264)

9 years, 8 months

1
0
0 / 0

[JBoss JIRA] (MODCLUSTER-116) Microcontainer does not always choose the right constructor when creating ModClusterService

by Michal Babacek (JIRA)

[ https://issues.jboss.org/browse/MODCLUSTER-116?page=com.atlassian.jira.pl... ] Michal Babacek closed MODCLUSTER-116. ------------------------------------- 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 > Microcontainer does not always choose the right constructor when creating ModClusterService > ------------------------------------------------------------------------------------------- > > Key: MODCLUSTER-116 > URL: https://issues.jboss.org/browse/MODCLUSTER-116 > Project: mod_cluster > Issue Type: Bug > Security Level: Public(Everyone can see) > Affects Versions: 1.1.0.Beta1 > Reporter: Paul Ferraro > Assignee: Paul Ferraro > Fix For: 1.1.0.CR1 > > > A user encountered the following error when attempting to start EAP 5.0.0 w/mod_cluster 1.1.0.Beta1: > 09:25:15,078 ERROR [AbstractKernelController] Error installing to Instantiated: name=ModClusterService state=Described mode=On Demand requiredState=Installed > java.lang.IllegalArgumentException: Wrong arguments. new for target java.lang.reflect.Constructor expected=[org.jboss.modcluster.config.ModClusterConfig, org.jboss.modcluster.load.LoadBalanceFactorProviderFactory] actual=[org.jboss.modcluster.config.ha.HAModClusterConfig, org.jboss.modcluster.load.impl.DynamicLoadBalanceFactorProvider] > at org.jboss.reflect.plugins.introspection.ReflectionUtils.handleErrors(ReflectionUtils.java:395) > The microcontainer is trying to instantiate ModClusterService using the wrong constructor. The mod_cluster-jboss-beans.xml should be updated to explicitly define the parameter types to remove this ambiguity. -- This message was sent by Atlassian JIRA (v6.2.6#6264)

9 years, 8 months

1
0
0 / 0

[JBoss JIRA] (MODCLUSTER-167) How does the UI deal with 20 or more servers

by Michal Babacek (JIRA)

[ https://issues.jboss.org/browse/MODCLUSTER-167?page=com.atlassian.jira.pl... ] Michal Babacek closed MODCLUSTER-167. ------------------------------------- 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 > How does the UI deal with 20 or more servers > -------------------------------------------- > > Key: MODCLUSTER-167 > URL: https://issues.jboss.org/browse/MODCLUSTER-167 > Project: mod_cluster > Issue Type: Feature Request > Security Level: Public(Everyone can see) > Affects Versions: 1.0.3.GA > Environment: All > Reporter: Jim Tyrrell > Assignee: Jean-Frederic Clere > Fix For: 1.1.0.Final > > Attachments: Screenshot-Mod_cluster Status - Mozilla Firefox-3.png > > > Should the mod_cluster-manager have a way to more easily deal with 10s even 100s of servers. Right now being able to handle more then 4-5 servers I think overwhelms the user. -- This message was sent by Atlassian JIRA (v6.2.6#6264)

9 years, 8 months

1
0
0 / 0

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

mod_cluster-issues August 2014