Правило сравнения стоимости суммы дает противоречивые результаты - слюни - PullRequest
Новая
       23

Правило сравнения стоимости суммы дает противоречивые результаты - слюни

0 голосов
/ 16 ноября 2018

Я унаследовал программу, которая использует drools api для запуска объектов SettlementMessage в определенных файлах правил drl. Эта программа работала последовательно около 8 лет в производстве. Теперь нас попросили перейти с Solaris SunOS на машины IBM AIX, и мы начали видеть некоторые противоречивые результаты с несколькими правилами, сравнивающими поле количества со значением. 

public class SettlementMessage implements Serializable {

    private double Amount=0;

    public double getAmount() {
        return Amount;
    }

    public void setAmount(double amount) {
        Amount = amount;
    }
.....

}

Правила, которые дают противоречивые результаты, определяются следующим образом: 

rule "Settlement Rule 1.1 - Large Settlement Amount For JPY and HUF - External Group"

    when
        $message: SettlementMessage(amount > 100000000.00, currencyCode in ("JPY","HUF"), settlementMethod in ("DIRECT_DEBIT","SWIFT", "SWIFT_EREL"))
    then 
        $message.setBusinessException("Exceeds Threshold - Confirm Settlement.");   
end


rule "Settlement Rule 1.2 - Large Settlement Amount For Others - External Group"

    when
        $message: SettlementMessage(amount > 3000000.00, currencyCode not in ("JPY","HUF"), settlementMethod in ("DIRECT_DEBIT","SWIFT", "SWIFT_EREL"))
    then 
        $message.setBusinessException("Exceeds Threshold - Confirm Settlement.");
end

Существует множество других правил, которые сопоставляют различные атрибуты объекта SettlementMessage с некоторыми значениями, и все работают должным образом. Мы видим только проблемы с этими правилами, сравнивающими объекты с количеством значительно ниже определенного порога.

Мы обрабатываем большое количество SettlementMessage объектов по этим правилам каждый день. Обычно, когда наступает системная дата, мы обрабатываем от 500 до 1500 SettlementMessage объектов. Объекты обрабатываются в последовательном порядке, а не параллельно. В большинстве дней большинство объектов обрабатывается правильно - если сумма ниже указанного порога, тогда правило не соответствует. Если сумма превышает указанный порог, то правило соответствует. В некоторые дни некоторые объекты некорректно сопоставляются с этими правилами (сумма ниже порогового значения, определенного в правиле). Мы видим примеры SettlementMessage объектов с количеством от 1 до 3000000, сопоставляемых с одним из правил (в зависимости от стоимости валюты). Java-программа, которая создает KieSession и запускает правила, упакована в файл jar и вызывается из адаптера Tibco Business Works. KieSession объект создается как PooledObject и повторно используется между несколькими вызовами для каждого SettlementMessage объекта. KieSession объект живет как PooledObject до тех пор, пока работает BW adapeter. SettlementMessage объект вставлен, fireAllRules вызван и SettlementMessage объект удален.

Некоторые интересные наблюдения: Когда мы получим объекты, которые были неправильно сопоставлены с этими правилами, если я повторно отправлю один и тот же (клон) SettlementMessage объект снова, он снова будет соответствовать этому правилу. Если я перезапущу адаптер BW и снова отправлю тот же объект, он будет обрабатываться правильно. Это похоже на KieSession или таблицы базовых решений как-то повреждены в памяти, но после перезапуска все возвращается в нормальное состояние. Исходное приложение использовало API Drools 5.0.1, и я переписал его, чтобы использовать вместо него Drools 7.12.0, и это не повлияло на поведение.

Кто-нибудь имеет представление, почему это сравнение величин может не совпадать по некоторым объектам в некоторые случайные дни? Есть ли способ переработать это правило для достижения той же логики, но с согласованными результатами (без несоответствия)? Я попытался немного изменить синтаксис этих правил, но безуспешно решил мою проблему. Самая большая проблема - при каждом изменении, которое я хочу попробовать, я не могу воспроизвести эту проблему на своем компьютере DEV, и мне нужно ждать несколько дней на компьютере IBM AIX, чтобы это повторилось.

На машинах SunOS работала Oracle Java.

Машины IBM AIX работают под управлением Java IBM J9 VM 2.9.

Буду признателен за понимание того, как переработать это правило, которое может оказать некоторое влияние на проблему, с которой я сталкиваюсь.

...