作業メモリからイベントを回避していないのは、必要なときにイベントを排除していない

Question

次の2つのルールがあります。

    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

そして、1日あたり10kのバックアップを生成し、50日間をシミュレートする「ストレステスト」。上記のルールはすべて3日間のウィンドウを指し、システムに他のルールがないことを考えると、50日後にはメモリに最大30kのイベントがあるはずです（成功したものは剪定する必要があるため）。ただし、ストリームエントリポイント（WorkingMemoryEntryPoint）の内容を確認すると、メモリには380Kイベントがあります。つまり、非常に古いイベントが自動的に排除されていないことを意味します。

KBはストリーム処理モードで構成されており、イベントは次のように定義されています。

declare Backup
    @role( event )
    @duration ( duration )
    @timestamp( finished )
end

したがって、明示的なライフサイクル管理はありません。私は何が間違っているのですか？ルール＃2と関係があることは知っています。なぜなら、それを削除すると、メモリで正確に30kのイベントを取得するからです（1日10k * 3日間の窓）

Answer 1

Droolsのバグであることが判明し、それ以来固定されています。

Answer 2

あなたの説明では、「後」演算子と例の時間枠との間に望ましくない相互作用があるかもしれないと思われます。

2番目のルールでは、スライディングウィンドウの使用をダンプして、「後」オペレーターをパラメーター化すると、探している効果を実現できます。例：

 rule "Prune Previous Successful Backups"
    @ruleId(2)
    when
        $prevBackup  : Backup($id : clientId,  state == BackupStateEnum.FINISHED) from entry-point "Backup Stream"
        $newerBackup : Backup(clientId == $id, state == BackupStateEnum.FINISHED, this after[0,3d] $prevBackup) from entry-point "Backup Stream"
    then
        drools.retract($prevBackup);
    end

いずれにせよ、DroolsチームのJiraを開いて、説明したように、スライドウィンドウとパラメーターレスの「後の」演算子との間の相互作用を調査できます。使用しているDroolsバージョンに言及することを忘れないでください。

エドソン