August 2013 - mod_cluster-issues - Jboss List Archives

[JBoss JIRA] (MODCLUSTER-336) configurable STATUS interval

by Jean-Frederic Clere (JIRA)

[ https://issues.jboss.org/browse/MODCLUSTER-336?page=com.atlassian.jira.pl... ] Jean-Frederic Clere resolved MODCLUSTER-336. -------------------------------------------- Resolution: Duplicate Issue > configurable STATUS interval > ---------------------------- > > Key: MODCLUSTER-336 > URL: https://issues.jboss.org/browse/MODCLUSTER-336 > Project: mod_cluster > Issue Type: Enhancement > Affects Versions: 1.2.4.Final > Reporter: Aaron Ogburn > Assignee: Jean-Frederic Clere > > The frequency of STATUS MCMPs is the backgroundProcessorDelay of the engine of the web system and there is no way to change it currently. > While there is not a way to change that backgroundProcessorDelay, can we add a configurable delay within mod_cluster instead? Maybe something like this wrapping the web engine background processor's calls into mod_cluster: > {code:java} > if (currentTime > lastStatus + delay) { > // handle STATUS > lastStatus = currentTime > } else > // do nothing > {code} > Thus the frequency of the background processor calls isn't changed as expected, but the frequency with which it can actually result in a STATUS MCMP through mod_cluster is. -- 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

11 years, 2 months

1
0
0 / 0

[JBoss JIRA] (MODCLUSTER-336) configurable STATUS interval

by Jean-Frederic Clere (JIRA)

[ https://issues.jboss.org/browse/MODCLUSTER-336?page=com.atlassian.jira.pl... ] Jean-Frederic Clere commented on MODCLUSTER-336: ------------------------------------------------ See MODCLUSTER-332. > configurable STATUS interval > ---------------------------- > > Key: MODCLUSTER-336 > URL: https://issues.jboss.org/browse/MODCLUSTER-336 > Project: mod_cluster > Issue Type: Enhancement > Affects Versions: 1.2.4.Final > Reporter: Aaron Ogburn > Assignee: Jean-Frederic Clere > > The frequency of STATUS MCMPs is the backgroundProcessorDelay of the engine of the web system and there is no way to change it currently. > While there is not a way to change that backgroundProcessorDelay, can we add a configurable delay within mod_cluster instead? Maybe something like this wrapping the web engine background processor's calls into mod_cluster: > {code:java} > if (currentTime > lastStatus + delay) { > // handle STATUS > lastStatus = currentTime > } else > // do nothing > {code} > Thus the frequency of the background processor calls isn't changed as expected, but the frequency with which it can actually result in a STATUS MCMP through mod_cluster is. -- 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

11 years, 2 months

1
0
0 / 0

[JBoss JIRA] (MODCLUSTER-332) Add Engine.getExecutor() to container SPI

by Jean-Frederic Clere (JIRA)

[ https://issues.jboss.org/browse/MODCLUSTER-332?page=com.atlassian.jira.pl... ] Jean-Frederic Clere commented on MODCLUSTER-332: ------------------------------------------------ org.jboss.modcluster.container.catalina.status-frequency value=6 will give a 60 STATUS message every seconds. > Add Engine.getExecutor() to container SPI > ----------------------------------------- > > Key: MODCLUSTER-332 > URL: https://issues.jboss.org/browse/MODCLUSTER-332 > Project: mod_cluster > Issue Type: Feature Request > Affects Versions: 1.2.3.Final > Reporter: Paul Ferraro > Assignee: Paul Ferraro > Fix For: 1.3.0.Alpha1, 1.2.5.Final > > > This is required to expose some mechanism to configure the STATUS interval. Currently, the web subsystem in AS7 has no mechanism to configure the background process period of the Engine. An Engine.getExecutor() container SPI method would allow the mod_cluster subsystem to configure its own executor to control this. -- 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

11 years, 2 months

1
0
0 / 0

[JBoss JIRA] (MODCLUSTER-338) Advertize adds a message digest even if security key is not configured

by Radoslav Husar (JIRA)

[ https://issues.jboss.org/browse/MODCLUSTER-338?page=com.atlassian.jira.pl... ] Radoslav Husar updated MODCLUSTER-338: -------------------------------------- Status: Pull Request Sent (was: Open) Git Pull Request: https://github.com/modcluster/mod_cluster/pull/18 > Advertize adds a message digest even if security key is not configured > ---------------------------------------------------------------------- > > Key: MODCLUSTER-338 > URL: https://issues.jboss.org/browse/MODCLUSTER-338 > Project: mod_cluster > Issue Type: Bug > Affects Versions: 1.2.4.Final > Reporter: Radoslav Husar > Assignee: Radoslav Husar > Fix For: 1.3.0.Alpha1 > > > As wireshark hints, the message digest is always included in the message even if the advertise security key is not configured. > This would not be such a problem if the salt actually used wouldn't be random bits from the memory. > This renders the digest completely useless since it can never be verified. -- 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

11 years, 2 months

1
0
0 / 0

[JBoss JIRA] (MODCLUSTER-337) If HTTPd sends a digest, require digest matching

by Radoslav Husar (JIRA)

[ https://issues.jboss.org/browse/MODCLUSTER-337?page=com.atlassian.jira.pl... ] Radoslav Husar updated MODCLUSTER-337: -------------------------------------- Status: Pull Request Sent (was: Open) Git Pull Request: https://github.com/modcluster/mod_cluster/pull/18 > If HTTPd sends a digest, require digest matching > ------------------------------------------------ > > Key: MODCLUSTER-337 > URL: https://issues.jboss.org/browse/MODCLUSTER-337 > Project: mod_cluster > Issue Type: Bug > Affects Versions: 1.2.4.Final > Reporter: Radoslav Husar > Assignee: Radoslav Husar > > Currently, mod_cluster server-side verifis the message digest only in case it has explicitely set advertize security key. However, if the HTTPd is configured to use security key we should require a digest check. -- 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

11 years, 2 months

1
0
0 / 0

[JBoss JIRA] (MODCLUSTER-338) Advertize adds a message digest even if security key is not configured

by Radoslav Husar (JIRA)

[ https://issues.jboss.org/browse/MODCLUSTER-338?page=com.atlassian.jira.pl... ] Radoslav Husar updated MODCLUSTER-338: -------------------------------------- Status: Resolved (was: Pull Request Sent) Resolution: Done Merged. > Advertize adds a message digest even if security key is not configured > ---------------------------------------------------------------------- > > Key: MODCLUSTER-338 > URL: https://issues.jboss.org/browse/MODCLUSTER-338 > Project: mod_cluster > Issue Type: Bug > Affects Versions: 1.2.4.Final > Reporter: Radoslav Husar > Assignee: Radoslav Husar > Fix For: 1.3.0.Alpha1 > > > As wireshark hints, the message digest is always included in the message even if the advertise security key is not configured. > This would not be such a problem if the salt actually used wouldn't be random bits from the memory. > This renders the digest completely useless since it can never be verified. -- 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

11 years, 2 months

1
0
0 / 0

[JBoss JIRA] (MODCLUSTER-337) If HTTPd sends a digest, require digest matching

by Radoslav Husar (JIRA)

[ https://issues.jboss.org/browse/MODCLUSTER-337?page=com.atlassian.jira.pl... ] Radoslav Husar updated MODCLUSTER-337: -------------------------------------- Status: Resolved (was: Pull Request Sent) Fix Version/s: 1.3.0.Alpha1 Resolution: Done Merged. > If HTTPd sends a digest, require digest matching > ------------------------------------------------ > > Key: MODCLUSTER-337 > URL: https://issues.jboss.org/browse/MODCLUSTER-337 > Project: mod_cluster > Issue Type: Bug > Affects Versions: 1.2.4.Final > Reporter: Radoslav Husar > Assignee: Radoslav Husar > Fix For: 1.3.0.Alpha1 > > > Currently, mod_cluster server-side verifis the message digest only in case it has explicitely set advertize security key. However, if the HTTPd is configured to use security key we should require a digest check. -- 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

11 years, 2 months

1
0
0 / 0

[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 updated MODCLUSTER-355: -------------------------------------- Status: Resolved (was: Pull Request Sent) Resolution: Done > 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

11 years, 2 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 updated MODCLUSTER-349: ------------------------------------------- Fix Version/s: 1.2.5.Final > 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 > Fix For: 1.2.5.Final > > 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

11 years, 2 months

1
0
0 / 0

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

by Jean-Frederic Clere (JIRA)

[ https://issues.jboss.org/browse/MODCLUSTER-168?page=com.atlassian.jira.pl... ] Jean-Frederic Clere updated MODCLUSTER-168: ------------------------------------------- Fix Version/s: 1.2.6.Final (was: 1.2.5.Final) > mod_cluster should use hostname provided in address instead a IP address > ------------------------------------------------------------------------ > > Key: MODCLUSTER-168 > URL: https://issues.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: Paul Ferraro > Fix For: 1.2.6.Final > > > 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, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira

11 years, 2 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