Bug 735732

Summary: Expiration is counted wrong for events in different package in CLOUD mode
Product: [JBoss] JBoss Enterprise BRMS Platform 5 Reporter: Tomas Schlosser <tschloss>
Component: BRE (Expert, Fusion)Assignee: Nobody <nobody>
Status: VERIFIED --- QA Contact: Lukáš Petrovický <lpetrovi>
Severity: urgent Docs Contact:
Priority: unspecified    
Version: BRMS 5.2.0.GACC: atangrin, lpetrovi, rzhang
Target Milestone: ---Keywords: Reopened
Target Release: BRMS 5.2.0.GA   
Hardware: Unspecified   
OS: Unspecified   
Whiteboard:
Fixed In Version: Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2011-09-20 09:53:36 UTC Type: Bug
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Attachments:
Description Flags
Simple test case none

Description Tomas Schlosser 2011-09-05 08:49:56 UTC
Created attachment 521450 [details]
Simple test case

Description of problem:
When an event is inserted into StatefulKnowledgeSession working in CLOUD mode, the event's expiration is wrongly counted as 0ms. The event is then retracted after fireAllRules() is called. If the fact is in the same package, the expiration offset is -1 as it should be.

Version-Release number of selected component (if applicable):
BRMS-5.3.0-ER3

How reproducible:
every time

Steps to Reproduce:
1. run the attached example
  
Actual results:
[EntryPointNode(4) EntryPoint::entryPoint ]
    [ObjectTypeNode(9)::EntryPoint::entryPoint objectType=[ClassObjectType event=org.jboss.qa.drools.expirescloud.TestEvent] expiration=0ms ]

Expected results:
[EntryPointNode(4) EntryPoint::entryPoint ]
    [ObjectTypeNode(9)::EntryPoint::entryPoint objectType=[ClassObjectType event=org.jboss.qa.drools.expirescloud.TestEvent] expiration=-1ms ]

Additional info:
If you change package in DRL file to org.jboss.qa.drools.expirescloud and change the value of pkg constant in ExpiresTest.java you get the correct result.

Comment 1 Lukáš Petrovický 2011-09-05 08:57:37 UTC
This breaks the expected behavior. Requesting blocker status.

Comment 2 Tihomir Surdilovic 2011-09-14 18:59:45 UTC
[from edson]

Lukas/Thomas

In CLOUD mode, expiration offset is completely ignored by the engine, because there is no event garbage collection. It is a STREAM mode exclusive feature.

Comment 3 Tomas Schlosser 2011-09-14 20:43:36 UTC
Well as it shows up it isn't ignored. Unless I explicitly specify @expires(1m) the events (declared in different) inserted into working memory are swept after calling fireAllRules(). I'll add listing of objects after tomorrow and add results. I think the right expiration offset for events in CLOUD mode is -1 (meaning it should never expire), but is 0 (therefore expires right away and is swept from memory).

Comment 4 Lukáš Petrovický 2011-09-15 04:53:07 UTC
The test case (attachment 521450 [details]) makes the bug quite obvious, please take a look at that.

Comment 5 Edson Tirelli 2011-09-20 00:36:30 UTC
Lukas, Tomas,

I am not sure what the problem here is... as per my previous comment, in CLOUD mode, the expiration offset is completely ignored by the runtime engine. It does not matter what value the attribute holds. 

I checked the attached test case and I don't see how that test shows any bug. Can you please clarify?

Comment 6 Tomas Schlosser 2011-09-20 09:53:36 UTC
This bug disappeared in BRMS-5.2.0.ER4. I'm therefore closing this bug.

Comment 7 Edson Tirelli 2011-09-27 18:32:08 UTC
I am reopening this ticket because Bug 724788 reintroduced this problem.

Comment 9 Tomas Schlosser 2011-09-30 08:07:05 UTC
This bug was fixed in BRMS-5.2.0.ER5, marking it verified.