Question

我的DRL文件：

package com.sample.eventmanagement;

import com.sample.eventmanagement.CheckInEvent    
import com.sample.eventmanagement.LateCheckInEvent     

global java.util.concurrent.BlockingQueue lateCheckInEntitiesQueue;    
global java.util.concurrent.BlockingQueue clearingLateCheckInEntitiesQueue;    

declare CheckInEvent    
 @role(event)    
 serialNum : String    
 currentCheckInTime : long    
end    

declare LateCheckInEvent    
 @role(event)    
 @expires( 120m )    
 serialNum : String    
 currentCheckInTime : long    
end    

rule "Raising an Late Check-In Alert"    
when     
    $s1: CheckInEvent( $serialNum : serialNum, $currentCheckInTime: currentCheckInTime ) from entry-point apCheckInStream    
    not( CheckInEvent( serialNum == $serialNum, currentCheckInTime > $currentCheckInTime, this after[ 1s, 360s ] $s1 ) from entry-point apCheckInStream)     
then     
    lateCheckInEntitiesQueue.add($s1);    
end    

rule "Clearing Late Check-In Alert"    
when     
    $s1: LateCheckInEvent( $serialNum : serialNum, $currentCheckInTime: currentCheckInTime ) from entry-point lateApCheckInStream    
    CheckInEvent( serialNum == $serialNum, currentCheckInTime > $currentCheckInTime) from entry-point clearingApCheckInStream    
then     
    System.out.println("Clearing late checkin " + $s1);    
    clearingLateCheckInEntitiesQueue.add($s1.getSerialNum());    
end

我在linux vm的karaf 2.4.3中以流模式运行drools，每5分钟报告一次10k实体checkinevent的内存不足。

我的用例是检测由serialnumber标识的实体的latecheckinevent。在晚签入事件中检测到将该事件泵送到另一规则并等待在2小时内从该实体再次正确签入。如果它发生，则规则2被触发。

我编写查询的方式有问题吗？？

Answer 1

事实将保留在你的会话中（在内存中），直到：

您手动撤消它们：使用UITableView或delete()
引擎撤回作为其真实维护系统的一部分：即逻辑插入的事实。
CEP引擎（fusion）检测到，由于涉及的约束，会话中不再需要标有retract()的事实。

您的情景似乎不属于这三种情况中的任何一种。

**顺便说一句，我还没有在您的DRL文件中看到过查询。

希望它有所帮助，

流模式下流口水：卡拉夫的OutOfMemory

1 个答案: