August 2013 - mod_cluster-issues - Jboss List Archives

[JBoss JIRA] (MODCLUSTER-355) Allow connector to not define maximum capacity (e.g. Undertow listener)

by Radoslav Husar (JIRA)

[ https://issues.jboss.org/browse/MODCLUSTER-355?page=com.atlassian.jira.pl... ] Radoslav Husar commented on MODCLUSTER-355: ------------------------------------------- PR: https://github.com/modcluster/mod_cluster/pull/39 > Allow connector to not define maximum capacity (e.g. Undertow listener) > ----------------------------------------------------------------------- > > Key: MODCLUSTER-355 > URL: https://issues.jboss.org/browse/MODCLUSTER-355 > Project: mod_cluster > Issue Type: Feature Request > Reporter: Radoslav Husar > Assignee: Radoslav Husar > Fix For: 1.3.0.Alpha1 > > > See WFLY-1888. > In WF we are wrapping Undertow listener with Connector interface. However, with all the async processing the maximum capacity does not represent busyness correctly. > I am going to add support for the connector to return "-1" that indicates to mod_cluster that this connector does not define maximum number of threads and leave the load calculation to capacity instead. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira

10 years, 8 months

1
0
0 / 0

[JBoss JIRA] (MODCLUSTER-355) Allow connector to not define maximum capacity (e.g. Undertow listener)

by Radoslav Husar (JIRA)

Radoslav Husar created MODCLUSTER-355: ----------------------------------------- Summary: Allow connector to not define maximum capacity (e.g. Undertow listener) Key: MODCLUSTER-355 URL: https://issues.jboss.org/browse/MODCLUSTER-355 Project: mod_cluster Issue Type: Feature Request Reporter: Radoslav Husar Assignee: Radoslav Husar Fix For: 1.3.0.Alpha1 See WFLY-1888. In WF we are wrapping Undertow listener with Connector interface. However, with all the async processing the maximum capacity does not represent busyness correctly. I am going to add support for the connector to return "-1" that indicates to mod_cluster that this connector does not define maximum number of threads and leave the load calculation to capacity instead. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira

10 years, 8 months

1
0
0 / 0

[JBoss JIRA] (MODCLUSTER-282) Add JGroups support

by Radoslav Husar (JIRA)

[ https://issues.jboss.org/browse/MODCLUSTER-282?page=com.atlassian.jira.pl... ] Radoslav Husar updated MODCLUSTER-282: -------------------------------------- Summary: Add JGroups support (was: Add JGRoups support) > Add JGroups support > ------------------- > > Key: MODCLUSTER-282 > URL: https://issues.jboss.org/browse/MODCLUSTER-282 > Project: mod_cluster > Issue Type: Feature Request > Affects Versions: 1.2.0.Final > Reporter: Jean-Frederic Clere > Assignee: Jean-Frederic Clere > Fix For: 1.3.0.Alpha1 > > > https://community.jboss.org/wiki/MOD-CLUSTERDiscoveryProtocol -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira

10 years, 8 months

1
0
0 / 0

[JBoss JIRA] (MODCLUSTER-303) Discovery protocol based on mod-cluster

by Radoslav Husar (JIRA)

[ https://issues.jboss.org/browse/MODCLUSTER-303?page=com.atlassian.jira.pl... ] Radoslav Husar updated MODCLUSTER-303: -------------------------------------- Assignee: Radoslav Husar (was: Vladimir Blagojevic) Fix Version/s: 1.3.0.Alpha1 (was: 1.1.4.Final ) I am going to try to target this for WildFly 8. Hm, but seems like there is an issue in the native part - MODCLUSTER-282 ? > Discovery protocol based on mod-cluster > --------------------------------------- > > Key: MODCLUSTER-303 > URL: https://issues.jboss.org/browse/MODCLUSTER-303 > Project: mod_cluster > Issue Type: Feature Request > Reporter: Vladimir Blagojevic > Assignee: Radoslav Husar > Fix For: 1.3.0.Alpha1 > > > In it previous life used to be https://issues.jboss.org/browse/JGRP-1322 > It would be nice to have a discovery protocol that can use mod-cluster as the source of the node information. > Mod-cluster already knows the list of participating nodes and provides this information in a well known format, so it could be simple to implement. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira

10 years, 8 months

1
0
0 / 0

[JBoss JIRA] (MODCLUSTER-354) Add support for Tomcat 8

by Radoslav Husar (JIRA)

Radoslav Husar created MODCLUSTER-354: ----------------------------------------- Summary: Add support for Tomcat 8 Key: MODCLUSTER-354 URL: https://issues.jboss.org/browse/MODCLUSTER-354 Project: mod_cluster Issue Type: Feature Request Reporter: Radoslav Husar Assignee: Radoslav Husar Fix For: 1.3.0.Alpha1 RC1 is already out http://tomcat.apache.org/download-80.cgi -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira

10 years, 8 months

1
0
0 / 0

[JBoss JIRA] (MODCLUSTER-353) SocketTimeoutException in DefaultMCMPHandler when using httpd 2.4.x

by Marco Danti (JIRA)

Marco Danti created MODCLUSTER-353: -------------------------------------- Summary: SocketTimeoutException in DefaultMCMPHandler when using httpd 2.4.x Key: MODCLUSTER-353 URL: https://issues.jboss.org/browse/MODCLUSTER-353 Project: mod_cluster Issue Type: Bug Affects Versions: 1.2.1.Final Environment: httpd-2.4.6 and mod_cluster-1.2.1.Final and above Reporter: Marco Danti Assignee: Jean-Frederic Clere After upgrading a web server from Apache 2.2.x (with mod_cluster 1.2.0) to Apache 2.4.6 (with mod_cluster 1.2.1.Final), when I bring up JBoss (7.2.0.Final) I start seeing repeated errors like the following: 14:45:36,777 INFO [org.jboss.modcluster.mcmp.impl.DefaultMCMPHandler] (ContainerBackgroundProcessor[StandardEngine[jboss.web]]) IO error sending command CONFIG to proxy stw-1.priv.softeco.it/172.16.0.133:6666: java.net.SocketTimeoutException: Read timed out at java.net.SocketInputStream.socketRead0(Native Method) [rt.jar:1.7.0_21] at java.net.SocketInputStream.read(SocketInputStream.java:150) [rt.jar:1.7.0_21] at java.net.SocketInputStream.read(SocketInputStream.java:121) [rt.jar:1.7.0_21] at sun.nio.cs.StreamDecoder.readBytes(StreamDecoder.java:283) [rt.jar:1.7.0_21] at sun.nio.cs.StreamDecoder.implRead(StreamDecoder.java:325) [rt.jar:1.7.0_21] at sun.nio.cs.StreamDecoder.read(StreamDecoder.java:177) [rt.jar:1.7.0_21] at java.io.InputStreamReader.read(InputStreamReader.java:184) [rt.jar:1.7.0_21] at java.io.BufferedReader.fill(BufferedReader.java:154) [rt.jar:1.7.0_21] at java.io.BufferedReader.readLine(BufferedReader.java:317) [rt.jar:1.7.0_21] at java.io.BufferedReader.readLine(BufferedReader.java:382) [rt.jar:1.7.0_21] at org.jboss.modcluster.mcmp.impl.DefaultMCMPHandler.sendRequest(DefaultMCMPHandler.java:670) at org.jboss.modcluster.mcmp.impl.DefaultMCMPHandler.sendRequests(DefaultMCMPHandler.java:437) at org.jboss.modcluster.mcmp.impl.DefaultMCMPHandler.status(DefaultMCMPHandler.java:385) at org.jboss.modcluster.mcmp.impl.DefaultMCMPHandler.status(DefaultMCMPHandler.java:349) at org.jboss.modcluster.ModClusterService.status(ModClusterService.java:468) at org.jboss.modcluster.container.catalina.CatalinaEventHandlerAdapter.lifecycleEvent(CatalinaEventHandlerAdapter.java:244) at org.apache.catalina.util.LifecycleSupport.fireLifecycleEvent(LifecycleSupport.java:115) [jbossweb-7.2.0.Final.jar:7.2.0.Final] at org.apache.catalina.core.ContainerBase.backgroundProcess(ContainerBase.java:1323) [jbossweb-7.2.0.Final.jar:7.2.0.Final] at org.apache.catalina.core.ContainerBase$ContainerBackgroundProcessor.processChildren(ContainerBase.java:1588) [jbossweb-7.2.0.Final.jar:7.2.0.Final] at org.apache.catalina.core.ContainerBase$ContainerBackgroundProcessor.run(ContainerBase.java:1574) [jbossweb-7.2.0.Final.jar:7.2.0.Final] at java.lang.Thread.run(Thread.java:722) [rt.jar:1.7.0_21] -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira

10 years, 8 months

1
0
0 / 0

[Community] Announcement: Planed outage: 2013-08-24 5:00 PM UTC

by Libor Krzyžanek

Libor Krzyžanek [https://community.jboss.org/people/lkrzyzanek] updated the announcement <b>Announcement</b>: "Planed outage: 2013-08-24 5:00 PM UTC" To view the announcement, visit: https://community.jboss.org/index.jspa -------------------------------------------------------------- Forums/Wiki/Blogs at community.jboss.org will be unavailable for about 4 hours due to upgrade. -------------------------------------------------------------- Announcement expires on August 28, 2013

10 years, 8 months

1
0
0 / 0

[JBoss JIRA] (MODCLUSTER-349) mod_manager truncates ENABLE-APP messages

by Jean-Frederic Clere (JIRA)

[ https://issues.jboss.org/browse/MODCLUSTER-349?page=com.atlassian.jira.pl... ] Jean-Frederic Clere edited comment on MODCLUSTER-349 at 8/14/13 5:33 AM: ------------------------------------------------------------------------- Fixed in all the branches. was (Author: jfclere): Fixed in all the batch. > mod_manager truncates ENABLE-APP messages > ----------------------------------------- > > Key: MODCLUSTER-349 > URL: https://issues.jboss.org/browse/MODCLUSTER-349 > Project: mod_cluster > Issue Type: Bug > Affects Versions: MOD_CLUSTER_1_0_10_GA_CP04, 1.2.4.Final > Environment: Windows Server 2008 > JBoss EAP 5.1.0 > EWS 1.0.1 > Reporter: Gregory Lardiere > Assignee: Jean-Frederic Clere > Attachments: ModCluster349.java, mod_cluster.patch > > > With lots of aliases, ENABLE-APP messages can be big enough to span several IP packets. > Sometimes, mod_manager will read only the first packet. > The message is therefore incomplete and mod_cluster configuration ends up corrupted : some aliases are missing and the context-root is replaced by "/". > This is caused by a wrong usage of ap_get_brigade() : it's called only once whereas it should be called until there's nothing left to read (see the attached patch). -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira

10 years, 8 months

1
0
0 / 0

[JBoss JIRA] (MODCLUSTER-349) mod_manager truncates ENABLE-APP messages

by Jean-Frederic Clere (JIRA)

[ https://issues.jboss.org/browse/MODCLUSTER-349?page=com.atlassian.jira.pl... ] Jean-Frederic Clere resolved MODCLUSTER-349. -------------------------------------------- Resolution: Done Fixed in all the batch. > mod_manager truncates ENABLE-APP messages > ----------------------------------------- > > Key: MODCLUSTER-349 > URL: https://issues.jboss.org/browse/MODCLUSTER-349 > Project: mod_cluster > Issue Type: Bug > Affects Versions: MOD_CLUSTER_1_0_10_GA_CP04, 1.2.4.Final > Environment: Windows Server 2008 > JBoss EAP 5.1.0 > EWS 1.0.1 > Reporter: Gregory Lardiere > Assignee: Jean-Frederic Clere > Attachments: ModCluster349.java, mod_cluster.patch > > > With lots of aliases, ENABLE-APP messages can be big enough to span several IP packets. > Sometimes, mod_manager will read only the first packet. > The message is therefore incomplete and mod_cluster configuration ends up corrupted : some aliases are missing and the context-root is replaced by "/". > This is caused by a wrong usage of ap_get_brigade() : it's called only once whereas it should be called until there's nothing left to read (see the attached patch). -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira

10 years, 8 months

1
0
0 / 0

[JBoss JIRA] (MODCLUSTER-347) mod_cluster-manager may break up aliases from a single VirtualHost, causing a messy page

by Jean-Frederic Clere (JIRA)

[ https://issues.jboss.org/browse/MODCLUSTER-347?page=com.atlassian.jira.pl... ] Jean-Frederic Clere resolved MODCLUSTER-347. -------------------------------------------- Fix Version/s: 1.2.5.Final Resolution: Done fixed by https://github.com/modcluster/mod_cluster/pull/35 > mod_cluster-manager may break up aliases from a single VirtualHost, causing a messy page > ---------------------------------------------------------------------------------------- > > Key: MODCLUSTER-347 > URL: https://issues.jboss.org/browse/MODCLUSTER-347 > Project: mod_cluster > Issue Type: Bug > Affects Versions: 1.2.4.Final > Environment: -JBoss Enterprise Application Platform (EAP 6.1.0) > -mod_cluster 1.2.4.Final > Reporter: Aaron Ogburn > Assignee: Jean-Frederic Clere > Fix For: 1.2.5.Final > > Attachments: mod_cluster-manager.html > > > Now that we properly show all the individual virtual hosts for a node, mod_cluster-manager may display a messy page with the aliases from a single Virtual Host broken up with multiple instances of the Virtual Host and its contexts. This can occur with our concurrent start ups now when JBoss has multiple applications bound to virtual servers that are deploying and enabling at once. The dump output demonstrates the cause: > balancer: [1] Name: mycluster Sticky: 1 [JSESSIONID]/[jsessionid] remove: 0 force: 0 Timeout: 0 maxAttempts: 1 > node: [1:1],Balancer: mycluster,JVMRoute: 4e6189af-0502-3305-8ff3-fad7fee8b516,LBGroup: [],Host: 127.0.0.1,Port: 8009,Type: ajp,flushpackets: 0,flushwait: 10,ping: 10,smax: 1,ttl: 60,timeout: 0 > host: 1 [example3.com] vhost: 3 node: 1 > host: 2 [example2.com] vhost: 3 node: 1 > host: 3 [example.com] vhost: 3 node: 1 > host: 4 [localhost] vhost: 3 node: 1 > host: 5 [example6.com] vhost: 1 node: 1 > host: 6 [example5.com] vhost: 1 node: 1 > host: 7 [example4.com] vhost: 1 node: 1 > host: 8 [testhost2] vhost: 1 node: 1 > host: 9 [default-host] vhost: 3 node: 1 > host: 10 [example9.com] vhost: 2 node: 1 > host: 11 [example8.com] vhost: 2 node: 1 > host: 12 [example7.com] vhost: 2 node: 1 > host: 13 [testhost3] vhost: 2 node: 1 > context: 1 [/helloworld2] vhost: 3 node: 1 status: 1 > context: 2 [/helloworld3] vhost: 1 node: 1 status: 1 > context: 3 [/] vhost: 2 node: 1 status: 1 > The messy html representative of this bad output is attached. Note host entry 9 is for vhost 3, but separated in the html from the other vhost 3 entries. > The problem is in manager_info_hosts. It assumes all of those entries will be in order, printing out the Virtual Host/Context lines whenever a different vhost entry is seen. It'd be much cleaner if we ensured each VirtualHost was only ever printed once on the page. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira

10 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 2013