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

以及每天生成 10K 次此类备份并模拟 50 天的“压力测试”。鉴于上述所有规则均指 3 天的窗口，并且系统中没有其他规则，因此 50 天后内存中最多应该有 30K 事件（更少，因为应该修剪成功的事件）。但是，当我检查流入口点（WorkingMemoryEntryPoint）的内容时，我在内存中有大约 380K 事件 - 这意味着我有一些非常旧的事件没有像它们应该的那样被自动驱逐。

KB配置为流处理模式，事件定义如下：


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

所以没有明确的生命周期管理。我究竟做错了什么 ？我知道它与规则 #2 有关，因为如果我删除它，我会在内存中准确地得到 30K 事件（每天 10K * 3 天窗口）

4

2 回答 2

0

根据您的描述，在您的示例中，“之后”运算符和时间窗口之间可能存在不希望的交互。

在您的第二条规则中，您可以尝试转储滑动窗口的使用并参数化“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 回答
0

原来是口水的一个错误，从那以后就修复了。

于 2012-12-20T05:14:39.400 回答