我有以下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事件(较少,因为应修剪成功的事件)。但是,当我检查流入口点的内容(WorkerMoryEntrypoint)时,我在内存中有〜380K事件 - 这意味着我有一些非常旧的事件,没有像应该一样自动驱逐。

KB是在流处理模式下配置的,事件的定义如下:


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

因此,没有明确的生命周期管理。我究竟做错了什么 ?我知道这与规则2有关,因为如果我删除它,我将在内存中完全得到30k事件(每天10k * 3天窗口)

有帮助吗?

解决方案 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,以调查滑动窗口和无参数“后”操作员之间的交互。不要忘记提及您正在使用的流口水版本。

埃德森

许可以下: CC-BY-SA归因
不隶属于 StackOverflow
scroll top