drools-fusion 在应该的时候没有从工作记忆中清除事件

发布于 2024-10-09 09:45:11 字数 1180 浏览 9 评论 0原文

我有以下 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 事件 - 这意味着我有一些非常旧的事件没有像它们应该的那样被自动驱逐。

知识库配置为流处理模式,事件定义如下:


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

因此没有显式的生命周期管理。 我做错了什么?我知道它与规则 #2 有关,因为如果我删除它,我会在内存中得到 30K 事件(每天 10K * 3 天窗口)

i have the following 2 rules:


    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

and a "stress test" that generates 10K such backups per day, and simulates 50 days. given that all the above rules refer to a 3 day window, and there are no other rules in the system, there should be at most 30K events in memory after 50 days (less, since successful ones should be pruned). however, when i check the contents of the stream entry-point (a WorkingMemoryEntryPoint), i have ~380K events in memory - which means i have some very old events not being evicted automatically like they should.

the KB was configured in stream processing mode, and an event is defined as follows:


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

so no explicit lifecycle management.
what am i doing wrong ? i know it has something to do with rule #2 because if i remove it i get exactly 30K events in memory (10K a day * 3 day window)

如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。

扫码二维码加入Web技术交流群

发布评论

需要 登录 才能够评论, 你可以免费 注册 一个本站的账号。

评论(2

拥抱影子 2024-10-16 09:45:11

根据您的描述,示例中的“after”运算符和时间窗口之间可能存在不需要的交互。

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

埃德森

It seems by your description that there might be an undesired interaction between the "after" operator and the time window in your example.

In your second rule, you can try dumping the use of the sliding windows and parameterize the "after" operator and it should achieve the effect you are looking for. Example:

 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

In any case, you can open a JIRA for the Drools team to investigate the interaction between sliding window and the parameterless "after" operator as you described. Don't forget to mention the Drools version you are using.

Edson

远昼 2024-10-16 09:45:11

原来是流口水的一个错误,此后已修复。

turned out to be a bug in drools, fixed since.

~没有更多了~
我们使用 Cookies 和其他技术来定制您的体验包括您的登录状态等。通过阅读我们的 隐私政策 了解更多相关信息。 单击 接受 或继续使用网站,即表示您同意使用 Cookies 和您的相关数据。
原文