у меня есть следующие 2 правила:Drools-фьюжн не evcting события из рабочей памяти, когда она должна
rule "Backup Not Succeeded For At Least 3 Days"
@ruleId(1)
when
Node($id : id)
not (Backup(clientId == $id, $state: state == BackupStateEnum.FINISHED) over window:time(3d) from entry-point "Backup Stream")
then
//nothing for now
end
rule "Prune Previous Successful Backups"
@ruleId(2)
when
$prevBackup : Backup($id : clientId, state == BackupStateEnum.FINISHED) over window:time(3d) from entry-point "Backup Stream"
$newerBackup : Backup(clientId == $id, state == BackupStateEnum.FINISHED, this after $prevBackup) over window:time(3d) from entry-point "Backup Stream"
then
drools.retract($prevBackup);
end
и «стресс-тест», который генерирует 10K таких резервных копий в день, и имитирующий 50 дней. учитывая, что все приведенные выше правила относятся к 3-дневному окну, и в системе нет других правил, должно быть не более 30K событий в памяти через 50 дней (меньше, так как успешные должны быть обрезаны). однако, когда я проверяю содержимое точки входа потока (WorkMemoryEntryPoint), у меня есть ~ 380K событий в памяти - это означает, что у меня есть некоторые очень старые события, которые не выселяются автоматически, как они должны.
КБ были сконфигурированы в режиме обработки потока, а событие определяются следующим образом:
declare Backup
@role(event)
@duration (duration)
@timestamp(finished)
end
поэтому нет явного управления жизненного цикла. что я делаю неправильно? Я знаю, что это имеет какое-то отношение к правилу № 2, потому что, если я его удалю, я получаю ровно 30 тыс. событий в памяти (10 тыс. в день * 3-дневное окно)
В итоге мне удалось воспроизвести проблему без каких-либо задействованных операторов: https://issues.jboss.org/browse/JBRULES-2862. выглядит просто, используя одни и те же окна дважды, чтобы вызвать утечку памяти – radai