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