March 2014 - mod_cluster-issues - Jboss List Archives

[JBoss JIRA] (MODCLUSTER-393) One can't change history and decay with DynamicLoadBalanceFactorProvider

by RH Bugzilla Integration (JIRA)

[ https://issues.jboss.org/browse/MODCLUSTER-393?page=com.atlassian.jira.pl... ] RH Bugzilla Integration updated MODCLUSTER-393: ----------------------------------------------- Bugzilla Update: Perform Bugzilla References: https://bugzilla.redhat.com/show_bug.cgi?id=1075215 > One can't change history and decay with DynamicLoadBalanceFactorProvider > ------------------------------------------------------------------------ > > Key: MODCLUSTER-393 > URL: https://issues.jboss.org/browse/MODCLUSTER-393 > Project: mod_cluster > Issue Type: Bug > Affects Versions: 1.2.6.Final > Reporter: Michal Babacek > Assignee: Radoslav Husar > Priority: Critical > Attachments: redacted_log > > > I'm under an ugly impression that one can't actually change {{history}} and {{decay}} attributes of *DynamicLoadBalanceFactorProvider*. > I was trying to figure out why the new test suite of CustomLoadMetric tests does not pass. In order to get load figures without history and decay manipulation, I set the following: > {code} > <subsystem xmlns="urn:jboss:domain:modcluster:1.2"> > <mod-cluster-config advertise-socket="modcluster" connector="ajp"> > <dynamic-load-provider history="0"> > <custom-load-metric class="biz.karms.modcluster.CustomLoadMetric" weight="1"> > <property name="capacity" value="1000"/> > <property name="loadfile" value="/tmp/mod_cluster-eapx/loadfileA"/> > <property name="parseexpression" value="^LOAD: ([0-9]*)$"/> > </custom-load-metric> > </dynamic-load-provider> > </mod-cluster-config> > </subsystem> > {code} > The aforementioned {{history=0}} effectively means that there is just 1 "slot" for a one historical value on which decay function should work. > If you take a look at the code in [DynamicLoadBalanceFactorProvider|https://github.com/modcluster/mod_cluste...] constructor, it is apparent > that the size of the List that later serves for storing the historical values is set sooner than the actual [setHistory(int history)|https://github.com/modcluster/mod_cluster/blob/master/core/src/m...] method is called. > The actual size of that List collection wouldn't do any harm by itself but it is being used in the aforementioned class with {{.size()}} to control cycles. > The same IMHO holds for the decay attribute. > Anyhow, I put some additional logging to the [DynamicLoadBalanceFactorProvider.java|https://github.com/modcluster/mod_c...]: > {code} > // Historical value contribute an exponentially decayed factor > for (int i = 0; i < queue.size(); ++i) { > double decay = 1 / Math.pow(decayFactor, i); > totalDecay += decay; > this.log.info("KTAG: totalLoad:"+totalLoad+", with decay:"+(totalLoad+queue.get(i).doubleValue() * decay)); > totalLoad += queue.get(i).doubleValue() * decay; > } > {code} > and > {code} > try { > // Normalize load with respect to capacity > this.recordLoad(metricLoadHistory, metric.getLoad(engine) / metric.getCapacity()); > this.log.info("KTAG metricLoadHistory:"+metricLoadHistory.toString()); > totalWeight += weight; > totalWeightedLoad += this.average(metricLoadHistory) * weight; > } catch (Exception e) { > this.log.error(e.getLocalizedMessage(), e); > } > {code} > with the following being the output: [^redacted_log]. > So, despite having {{history=0}}, which should force the system to keep just 1, the current value, {{metricLoadHistory}} grew from > {noformat} > KTAG metricLoadHistory:[0.8] > {noformat} > to > {noformat} > KTAG metricLoadHistory:[0.9, 0.9, 0.9, 0.9, 0.9, 0.9, 0.9, 0.9, 0.9, 0.8] > {noformat} > which is exactly [9|https://github.com/modcluster/mod_cluster/blob/master/core/src/main/jav...] + [1|https://github.com/modcluster/mod_cluster/blob/master/core/src/main/jav...] in size :-) > WDYT? -- 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, 1 month

1
0
0 / 0

[JBoss JIRA] (MODCLUSTER-393) One can't change history and decay with DynamicLoadBalanceFactorProvider

by Michal Babacek (JIRA)

[ https://issues.jboss.org/browse/MODCLUSTER-393?page=com.atlassian.jira.pl... ] Michal Babacek updated MODCLUSTER-393: -------------------------------------- Attachment: redacted_log > One can't change history and decay with DynamicLoadBalanceFactorProvider > ------------------------------------------------------------------------ > > Key: MODCLUSTER-393 > URL: https://issues.jboss.org/browse/MODCLUSTER-393 > Project: mod_cluster > Issue Type: Bug > Affects Versions: 1.2.6.Final > Reporter: Michal Babacek > Assignee: Radoslav Husar > Priority: Critical > Attachments: redacted_log > > > I'm under an ugly impression that one can't actually change {{history}} and {{decay}} attributes of *DynamicLoadBalanceFactorProvider*. > I was trying to figure out why the new test suite of CustomLoadMetric tests does not pass. In order to get load figures without history and decay manipulation, I set the following: > {code} > <subsystem xmlns="urn:jboss:domain:modcluster:1.2"> > <mod-cluster-config advertise-socket="modcluster" connector="ajp"> > <dynamic-load-provider history="0"> > <custom-load-metric class="biz.karms.modcluster.CustomLoadMetric" weight="1"> > <property name="capacity" value="1000"/> > <property name="loadfile" value="/tmp/mod_cluster-eapx/loadfileA"/> > <property name="parseexpression" value="^LOAD: ([0-9]*)$"/> > </custom-load-metric> > </dynamic-load-provider> > </mod-cluster-config> > </subsystem> > {code} > The aforementioned {{history=0}} effectively means that there is just 1 "slot" for a one historical value on which decay function should work. > If you take a look at the code in [DynamicLoadBalanceFactorProvider|https://github.com/modcluster/mod_cluste...] constructor, it is apparent > that the size of the List that later serves for storing the historical values is set sooner than the actual [setHistory(int history)|https://github.com/modcluster/mod_cluster/blob/master/core/src/m...] method is called. > The actual size of that List collection wouldn't do any harm by itself but it is being used in the aforementioned class with {{.size()}} to control cycles. > The same IMHO holds for the decay attribute. > Anyhow, I put some additional logging to the [DynamicLoadBalanceFactorProvider.java|https://github.com/modcluster/mod_c...]: > {code} > // Historical value contribute an exponentially decayed factor > for (int i = 0; i < queue.size(); ++i) { > double decay = 1 / Math.pow(decayFactor, i); > totalDecay += decay; > this.log.info("KTAG: totalLoad:"+totalLoad+", with decay:"+(totalLoad+queue.get(i).doubleValue() * decay)); > totalLoad += queue.get(i).doubleValue() * decay; > } > {code} > and > {code} > try { > // Normalize load with respect to capacity > this.recordLoad(metricLoadHistory, metric.getLoad(engine) / metric.getCapacity()); > this.log.info("KTAG metricLoadHistory:"+metricLoadHistory.toString()); > totalWeight += weight; > totalWeightedLoad += this.average(metricLoadHistory) * weight; > } catch (Exception e) { > this.log.error(e.getLocalizedMessage(), e); > } > {code} > with the following being the output: [^redacted_log]. > So, despite having {{history=0}}, which should force the system to keep just 1, the current value, {{metricLoadHistory}} grew from > {noformat} > KTAG metricLoadHistory:[0.8] > {noformat} > to > {noformat} > KTAG metricLoadHistory:[0.9, 0.9, 0.9, 0.9, 0.9, 0.9, 0.9, 0.9, 0.9, 0.8] > {noformat} > which is exactly [9|https://github.com/modcluster/mod_cluster/blob/master/core/src/main/jav...] + [1|https://github.com/modcluster/mod_cluster/blob/master/core/src/main/jav...] in size :-) > WDYT? -- 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, 1 month

1
0
0 / 0

[JBoss JIRA] (MODCLUSTER-392) mod_proxy_cluster.c doesn't compile with httpd 2.2.22

by Michal Babacek (JIRA)

[ https://issues.jboss.org/browse/MODCLUSTER-392?page=com.atlassian.jira.pl... ] Michal Babacek resolved MODCLUSTER-392. --------------------------------------- Resolution: Done Resolved. > mod_proxy_cluster.c doesn't compile with httpd 2.2.22 > ----------------------------------------------------- > > Key: MODCLUSTER-392 > URL: https://issues.jboss.org/browse/MODCLUSTER-392 > Project: mod_cluster > Issue Type: Bug > Affects Versions: 1.3.1.Final > Reporter: Michal Babacek > Assignee: Michal Babacek > Priority: Critical > Fix For: 1.3.1.Final > > > {code} > d_proxy_cluster.c: In function 'proxy_cluster_post_request': > mod_proxy_cluster.c:3943: error: 'proxy_worker_stat' has no member named 'name' > {code} -- 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, 1 month

1
0
0 / 0

[JBoss JIRA] (MODCLUSTER-392) mod_proxy_cluster.c doesn't compile with httpd 2.2.22

by Michal Babacek (JIRA)

[ https://issues.jboss.org/browse/MODCLUSTER-392?page=com.atlassian.jira.pl... ] Michal Babacek closed MODCLUSTER-392. ------------------------------------- > mod_proxy_cluster.c doesn't compile with httpd 2.2.22 > ----------------------------------------------------- > > Key: MODCLUSTER-392 > URL: https://issues.jboss.org/browse/MODCLUSTER-392 > Project: mod_cluster > Issue Type: Bug > Affects Versions: 1.3.1.Final > Reporter: Michal Babacek > Assignee: Michal Babacek > Priority: Critical > Fix For: 1.3.1.Final > > > {code} > d_proxy_cluster.c: In function 'proxy_cluster_post_request': > mod_proxy_cluster.c:3943: error: 'proxy_worker_stat' has no member named 'name' > {code} -- 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, 1 month

1
0
0 / 0

[JBoss JIRA] (MODCLUSTER-393) One can't change history and decay with DynamicLoadBalanceFactorProvider

by Michal Babacek (JIRA)

Michal Babacek created MODCLUSTER-393: ----------------------------------------- Summary: One can't change history and decay with DynamicLoadBalanceFactorProvider Key: MODCLUSTER-393 URL: https://issues.jboss.org/browse/MODCLUSTER-393 Project: mod_cluster Issue Type: Bug Affects Versions: 1.2.6.Final Reporter: Michal Babacek Assignee: Radoslav Husar Priority: Critical I'm under an ugly impression that one can't actually change {{history}} and {{decay}} attributes of *DynamicLoadBalanceFactorProvider*. I was trying to figure out why the new test suite of CustomLoadMetric tests does not pass. In order to get load figures without history and decay manipulation, I set the following: {code} <subsystem xmlns="urn:jboss:domain:modcluster:1.2"> <mod-cluster-config advertise-socket="modcluster" connector="ajp"> <dynamic-load-provider history="0"> <custom-load-metric class="biz.karms.modcluster.CustomLoadMetric" weight="1"> <property name="capacity" value="1000"/> <property name="loadfile" value="/tmp/mod_cluster-eapx/loadfileA"/> <property name="parseexpression" value="^LOAD: ([0-9]*)$"/> </custom-load-metric> </dynamic-load-provider> </mod-cluster-config> </subsystem> {code} The aforementioned {{history=0}} effectively means that there is just 1 "slot" for a one historical value on which decay function should work. If you take a look at the code in [DynamicLoadBalanceFactorProvider|https://github.com/modcluster/mod_cluste...] constructor, it is apparent that the size of the List that later serves for storing the historical values is set sooner than the actual [setHistory(int history)|https://github.com/modcluster/mod_cluster/blob/master/core/src/m...] method is called. The actual size of that List collection wouldn't do any harm by itself but it is being used in the aforementioned class with {{.size()}} to control cycles. The same IMHO holds for the decay attribute. Anyhow, I put some additional logging to the [DynamicLoadBalanceFactorProvider.java|https://github.com/modcluster/mod_c...]: {code} // Historical value contribute an exponentially decayed factor for (int i = 0; i < queue.size(); ++i) { double decay = 1 / Math.pow(decayFactor, i); totalDecay += decay; this.log.info("KTAG: totalLoad:"+totalLoad+", with decay:"+(totalLoad+queue.get(i).doubleValue() * decay)); totalLoad += queue.get(i).doubleValue() * decay; } {code} and {code} try { // Normalize load with respect to capacity this.recordLoad(metricLoadHistory, metric.getLoad(engine) / metric.getCapacity()); this.log.info("KTAG metricLoadHistory:"+metricLoadHistory.toString()); totalWeight += weight; totalWeightedLoad += this.average(metricLoadHistory) * weight; } catch (Exception e) { this.log.error(e.getLocalizedMessage(), e); } {code} with the following being the output: [^redacted_log]. So, despite having {{history=0}}, which should force the system to keep just 1, the current value, {{metricLoadHistory}} grew from {noformat} KTAG metricLoadHistory:[0.8] {noformat} to {noformat} KTAG metricLoadHistory:[0.9, 0.9, 0.9, 0.9, 0.9, 0.9, 0.9, 0.9, 0.9, 0.8] {noformat} which is exactly [9|https://github.com/modcluster/mod_cluster/blob/master/core/src/main/jav...] + [1|https://github.com/modcluster/mod_cluster/blob/master/core/src/main/jav...] in size :-) WDYT? -- 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, 1 month

1
0
0 / 0

[JBoss JIRA] (MODCLUSTER-329) Add ModClusterService methods to obtain status of a context

by Jean-Frederic Clere (JIRA)

[ https://issues.jboss.org/browse/MODCLUSTER-329?page=com.atlassian.jira.pl... ] Jean-Frederic Clere updated MODCLUSTER-329: ------------------------------------------- Fix Version/s: 1.2.9.Final (was: 1.2.8.Final) > Add ModClusterService methods to obtain status of a context > ----------------------------------------------------------- > > Key: MODCLUSTER-329 > URL: https://issues.jboss.org/browse/MODCLUSTER-329 > Project: mod_cluster > Issue Type: Feature Request > Affects Versions: 1.2.3.Final > Reporter: Paul Ferraro > Assignee: Paul Ferraro > Fix For: 1.2.9.Final > > > In order for AS7 management operations like "stop-context" to figure out how to properly rollback, they need to know the initial status of the context. -- 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, 1 month

1
0
0 / 0

[JBoss JIRA] (MODCLUSTER-391) mod_cluster and mod_proxy integration

by Jean-Frederic Clere (JIRA)

[ https://issues.jboss.org/browse/MODCLUSTER-391?page=com.atlassian.jira.pl... ] Jean-Frederic Clere updated MODCLUSTER-391: ------------------------------------------- Fix Version/s: 1.2.9.Final (was: 1.2.8.Final) > mod_cluster and mod_proxy integration > ------------------------------------- > > Key: MODCLUSTER-391 > URL: https://issues.jboss.org/browse/MODCLUSTER-391 > Project: mod_cluster > Issue Type: Bug > Affects Versions: 1.2.6.Final > Environment: All platforms we build mod_cluster for. > Reporter: Michal Babacek > Assignee: Jean-Frederic Clere > Labels: native_libraries > Fix For: 1.3.1.Final, 1.2.9.Final > > Attachments: error_log, mod_cluster.conf, mod_proxy.conf, standalone-ha.xml > > > This Jira encapsulates all concerns regarding mod_cluster - mod_proxy integration. For instance, while basic {{ProxyPass}} settings work just fine, e.g. serving some files on {{/static}} from the Apache HTTP itself: > {code} > ProxyPassMatch ^/static/ ! > ProxyPass / balancer://qacluster stickysession=JSESSIONID|jsessionid nofailover=on > ProxyPassReverse / balancer://qacluster > ProxyPreserveHost on > {code} > there are more complex setups, involving {{BalancerMember}} configurations, that do not work as expected. In the following example, one wanted to have {{/clusterbench}} application managed by mod_cluster, dynamically, while at the same time, in a different VirtualHost, having {{/tses}} application handled by manually created mod_proxy balancer settings. > Attached [^mod_cluster.conf], [^mod_proxy.conf], [^standalone-ha.xml](modcluster subsystem element only) and [^error_log]. > The aforementioned setup resulted in: > |HTTP 200|(From worker)|http://10.16.88.19:8847/clusterbench/requestinfo/|OK|(/)| > |HTTP 404|(From httpd)|http://10.16.88.19:8847/tses/session.jsp|Expected fail|(/)| > |HTTP 503|(From httpd)|http://10.16.88.19:2182/tses/session.jsp|Unexpected fail|(x)| -- 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, 1 month

1
0
0 / 0

[JBoss JIRA] (MODCLUSTER-389) standby worker doesn't work.

by Jean-Frederic Clere (JIRA)

[ https://issues.jboss.org/browse/MODCLUSTER-389?page=com.atlassian.jira.pl... ] Jean-Frederic Clere updated MODCLUSTER-389: ------------------------------------------- Fix Version/s: 1.2.9.Final (was: 1.2.8.Final) > standby worker doesn't work. > ---------------------------- > > Key: MODCLUSTER-389 > URL: https://issues.jboss.org/browse/MODCLUSTER-389 > Project: mod_cluster > Issue Type: Bug > Affects Versions: 1.2.7.Final, 1.3.0.Final > Reporter: Jean-Frederic Clere > Assignee: Jean-Frederic Clere > Fix For: 1.3.1.Final, 1.2.9.Final > > > While using <simple-load-provider factor="0"/> (which creates a hoy standby node). > 1- WildFly/AS complain the factor=0 isn't valid. > 2 - the status of the node stays in error. -- 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, 1 month

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.9.Final (was: 1.2.8.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.9.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

10 years, 1 month

1
0
0 / 0

[JBoss JIRA] (MODCLUSTER-363) Rather unsettling warnings in Solaris build logs

by Jean-Frederic Clere (JIRA)

[ https://issues.jboss.org/browse/MODCLUSTER-363?page=com.atlassian.jira.pl... ] Jean-Frederic Clere updated MODCLUSTER-363: ------------------------------------------- Fix Version/s: 1.2.9.Final (was: 1.2.8.Final) > Rather unsettling warnings in Solaris build logs > ------------------------------------------------ > > Key: MODCLUSTER-363 > URL: https://issues.jboss.org/browse/MODCLUSTER-363 > Project: mod_cluster > Issue Type: Bug > Affects Versions: 1.2.6.Final > Environment: Solaris sparc, x86 > Reporter: Michal Babacek > Assignee: Jean-Frederic Clere > Fix For: 1.2.9.Final > > > Configure and compilation steps e.g. in these builds: [mod_cluster-solaris10-sparc64|https://jenkins.mw.lab.eng.bos.redhat.com/h...] and [mod_cluster-solaris10-x86|https://jenkins.mw.lab.eng.bos.redhat.com/hudso...]. > Bugspotter: [~vtunka] -- 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, 1 month

1
0
0 / 0

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

mod_cluster-issues March 2014