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