Sabrools-Fusion evcieren Ereignisse nicht aus dem Arbeitsgedächtnis, wenn es sollte, wenn es sollte

Question

Ich habe die folgenden 2 Regeln:

    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

und ein "Stresstest", der 10.000 solche Backups pro Tag erzeugt und 50 Tage simuliert. Angesichts der Tatsache, dass sich alle oben genannten Regeln auf ein 3 -Tage -Fenster beziehen und es keine anderen Regeln im System gibt, sollten nach 50 Tagen höchstens 30.000 Ereignisse im Speicher vorhanden sein (weniger, da erfolgreiche erfolgreiche beschnitten werden sollten). Wenn ich jedoch den Inhalt des Stream -Einstiegspunkts (ein WorkingMemoryEnryPoint) überprüfe, habe ich ~ 380K -Ereignisse im Speicher - was bedeutet, dass ich einige sehr alte Ereignisse habe, die nicht automatisch so vertrieben werden.

Der KB wurde im Stream -Verarbeitungsmodus konfiguriert und ein Ereignis wird wie folgt definiert:

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

Also kein explizites Lebenszyklusmanagement. Was mache ich falsch ? Ich weiß, dass es etwas mit Regel 2 zu tun hat, denn wenn ich es entferte, bekomme ich genau 30.000 Ereignisse im Speicher (10k pro Tag * 3 -Tage -Fenster)

Answer 1

Es stellte sich heraus, dass es sich um einen Fehler in Sabbern handelte, seitdem behoben.

Answer 2

Nach Ihrer Beschreibung scheint es möglicherweise eine unerwünschte Interaktion zwischen dem "After" -Operator und dem Zeitfenster in Ihrem Beispiel zu geben.

In Ihrer zweiten Regel können Sie versuchen, die Verwendung der Gleitfenster zu entlasten und den "After" -Operator zu parametriieren, und es sollte den Suchseffekt erzielen. Beispiel:

 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 jedem Fall können Sie eine JIRA für das Drools -Team öffnen, um die Interaktion zwischen Schiebebefenster und dem parameterlosen "nach" Operator wie Sie beschrieben "zu untersuchen. Vergessen Sie nicht, die von Ihnen verwendete Drools -Version zu erwähnen.

Edson