Правило сравнения стоимости суммы дает противоречивые результаты - слюни
Я унаследовал программу, которая использует 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.
Буду признателен за понимание того, как переработать это правило, которое может оказать некоторое влияние на проблему, с которой я сталкиваюсь.