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

[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_cluster/blob/master/core/src/main/java/org/jboss/modcluster/load/impl/DynamicLoadBalanceFactorProvider.java#L54] 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/main/java/org/jboss/modcluster/load/impl/DynamicLoadBalanceFactorProvider.java#L177] 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_cluster/blob/master/core/src/main/java/org/jboss/modcluster/load/impl/DynamicLoadBalanceFactorProvider.java]:

{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/java/org/jboss/modcluster/load/impl/DynamicLoadBalanceFactorProvider.java#L50] + [1|https://github.com/modcluster/mod_cluster/blob/master/core/src/main/java/org/jboss/modcluster/load/impl/DynamicLoadBalanceFactorProvider.java#L54] 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