2

私は次の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 日あたり 10,000 のそのようなバックアップを生成し、50 日間をシミュレートする「ストレス テスト」。上記のすべてのルールが 3 日間のウィンドウを参照しており、システムに他のルールがない場合、50 日後にメモリ内のイベントは最大で 30K になるはずです (成功したイベントは削除する必要があるため、それより少なくなります)。ただし、ストリーム エントリ ポイント (WorkingMemoryEntryPoint) の内容を確認すると、メモリ内に ~380K のイベントがあります。つまり、非常に古いイベントが自動的に削除されていません。

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


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

したがって、明示的なライフサイクル管理はありません。私は何を間違っていますか？ルール＃2と関係があることはわかっています。これを削除すると、メモリ内に正確に30Kのイベントが発生するためです（1日10K * 3日のウィンドウ）

4

2 に答える 2

0

それ以来修正された、よだれのバグであることが判明しました。

于 2012-12-20T05:14:39.400 に答える
0

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

2 番目のルールでは、スライディング ウィンドウの使用をダンプし、「after」演算子をパラメーター化して、探している効果を達成することができます。例：

 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 を開いて、説明したように、スライディング ウィンドウとパラメーターなしの「after」オペレーターとの間の相互作用を調査できます。使用している Drools のバージョンを忘れずに記載してください。

エドソン

于 2011-01-28T16:05:33.037 に答える